I occasionally visit this forum to relax...

Hello, All Unfortunately, I currently do not have the time or opportunity to conduct any real developments (although the longer it lasts, the stronger the desire to return and do something like that...) So, another crazy idea on the theme of Flat Address Space on the Z80. This is not detailed study, but maybe someone can do something based on this real. So, let's remember the i8086 Its registers were also 16-bit, and 64 kb could also be addressed. To overcome this barrier, they used segment registers. There were 4 of them; CS; (code), DS (data), SS (stack), ES (optional). They contained the senior part of the address. There are no segment registers on the Z80. What if we implement them using ports I/O instead of switching banks? Of course, we will need the most true north bridge - a circuit that connects the external bus, CPU and memory controller. As you know, the Z80 has M1 lines (indicates that at the specified address we read command), WR and RD (writing and reading into memory, respectively). In total, by external means we can distinguish three states: 1. The CPU reads the command code. 2. The CPU is reading the data. 3. The CPU writes data. Now we introduce three input/output ports: 1. CSP - Command segment port. 2. RSP - Read data segment port. 3. WSP - Write data segment port.We get a segmented model, in which, unlike the page model, we do not locked within a 16 kb page. We can have as much as 64 kB of executable code, another 64 kb of data, and at the same time we can carry out intersegment transfer data by writing a value other than RSP to WSP. Problem N1; stack.; Obviously, when RSP != WSP use a stack difficult. Before returning, you need to set RSP equal to WSP at the time call, otherwise we will arrive at the wrong place. Problem N2; interrupts.; Actually, what is added to the previous problem is that where will we take the vector from? Unfortunately, I’m not an expert here because the topic is interruptions The Z80 was extremely poorly covered in Spectrum practice. However, it is worth remembering device called "Interrupt Controller" which is mentioned in literature on Z80 and serves to implement IM 0. Therefore - there is the ability to determine from the outside that the CPU is about to move to a handler interruptions. If so, then the following measures can be taken: 1. It should be possible to read the value of CSP, RSP and WSP at any time. 2. Enter ISP - Interrupt segment port. Northbridge, detecting that the CPU switched to interrupt processing mode, sets the ISP value as pointer to the instruction segment instead of the CSP and the CPU starts working in this segment. All registers are already saved on the stack of the RSP segment, you can work. Exit frominterrupt processing mode (reverse replacement of ISP with CSP) can be done using command RETI/RETN, or maybe just some manipulation with one of Northbridge port managers. Problem N3; intersegmental; transitions. This can be easily resolved by adding Northbridge has a little more intelligence. You can make it work, say as follows: ┌─- CODE ─── 007F54 LD A,#01 007F56 OUT(CSR),A ; Installed a new segment 007F57 JP 9E3B ; The following command is still executed in ; old segment. It doesn't have to be JP, it can ; be JR, CALL, RST, even NOP. 019E3B; That's it, we've arrived in a new segment. └── CODE ─── As a treat, you can add an automatic increment of the CSR value when read by the processor KOP at address 0xFFFF. This way we can afford safely run programs longer than 64 kb. Who will say what?

Hello Sonic Very good idea. There is a proposal to speed up inter-segment transitions (and returns). Instead of three machine commands shown in a piece of code can be defined for this purpose undocumented commands from table #ED. The battery will be released, etc., and etc. :)

Hello Sonic Son> Scheme, principle - to the studio! Son> Why is it still not available in implementations??? Son> This mechanism has been used in MSXs for a long time. As an example, look at the diagram of a memory module for MSX with a capacity of 1 MB. File: msx1mb.zip http://zx.pk.ru/attachment.php?attachmentid=3928

Hello Sonic This must have been interesting to do about 15 years ago. Zilog long ago came up with a mechanism for its processors memory expansion MMU -Memory Management Unit. An expansion scheme up to 4 MB is easily implemented using two IR26 registers (74xx670) and one ID7 decoder (74xx138).

Hello caro car> This was probably interesting to do about 15 years ago. car> Zilog came up with a mechanism for its processors long ago car> memory expansion MMU -Memory Menegement Unit. car> An expansion scheme up to 4 MB is easily implemented using two IR26 registers car> (74xx670) car> and one ID7 decoder (74xx138). The scheme, the principle - into the studio! Why are there still no implementations??? Damn, maybe there will be a take-2 - I’ll continue resuscitation of Pentagon-48. Hot on it skate something like that...

Hello Sonic car> 1. CSP - Command segment port. car> 2. RSP - Read data segment port. car> 3. WSP - Write data segment port. car> We obtain a segmented model in which, unlike the page model, car> we are not locked within a 16 kb page. We can have as much as 64 kb car> executable code, another 64 kb of data, and at the same time we can implement car> intersegment data transfer by writing a different value to the WSP car> from RSP. it won’t work - according to M1, this is exactly what the COP is read, and the arguments - in particular the constants will be taken from God knows where. example - ld hl,nn ld (hl),n jp nn ....

Hello, The Exploited The> Quote: The> Posted by caro The> 1. CSP - Command segment port. The> 2. RSP - Read data segment port. The> 3. WSP - Write data segment port. The> We obtain a segmented model in which, unlike the page model, The> we are not locked into a 16kb page. We can have as much as 64 kb The> executable code, another 64 kB of data, and at the same time we can implement The> intersegment data transfer by writing a different value to the WSP The> from RSP. The> The> will not work - according to M1, this is exactly what the COP is read, and the arguments are in The> particular constants will be taken from God knows where. The> example - ld hl,nn ld (hl),n jp nn .... And even if it were possible, it does not solve the malloc(65536) problem. And What for is a computer with megabytes of memory if you need to tinker with assembly language? pieces of memory? And if malloc(65536) is unsolvable, then dispatchers shouldn’t bother makes sense: in CP/M with 48k RAM TPA has been able to do this for 25 years already work with so-called “overlays” - overlap the code/data area with codefrom disk files. We drive these files onto a fast electronic disk (any structures) - and we obtain a solution on a standard basis. It was a lyrical digression. In fact, I agree - dispatcher at 16k is only suitable for organizing an electronic disk from "extra RAM", it is more good for little. The 64k page manager is less convenient for email. disk (slower), but it allows you to easily organize a "dial-up" multitasking" - it's as easy as shelling pears to switch "entire" pages via NMI. Having cramming such a dispatcher and a bunch of RAM into, for example, UZI is as easy as shelling pears: it won’t be possible very slow - the problem with swapping to a slow drive will not be the same a problem that it became for the author of UZI due to the lack of RAM. Those. Having both types of dispatchers is useful, and not only (and maybe not at all for in order to emulate address space expansion. Another corollary thought: an efficient compiler (for example, C) for subcomputers capable of compiling compact code is an absolutely thing necessary, having it, maybe 64k will be enough... And here’s the paradox - still not of this, and there is a sea of dispatchers of different options. By the way, and by switching the compiler itself can deal with pages, there will be no need to fence the hardware wiring (a simple dispatcher based on a register and a multiplexer will be sufficient), and in general remember about dispatchers.

Hello, Error404 Well then, gentlemen Z180... There are no problems with the Flat memory model. Internal ports are relocated, this function can be performed by BootROM. As for the software, regarding the compiler... Good idea though. I think if you develop it, you need to start with a certain standardization of memory cards. Come up with a new executable file format and introduce the concept of segments. Consider the standard ZX. We have: 16K ROM 16K screen (conditionally) 16 K - let's call it resident area 16 K - let's call it page area Our binary should be able to: 1. Have an arbitrary length. 2. Have an arbitrary number of segments with a length of no more than 16 kb. 3. Have the concept of a segment attribute. One of the segments may have the attribute Resident - it is he who gets to 0x8000. The remaining segments can be loaded into arbitrary pages with 0xC000. There are two segments left: ROM and Screen. Here I will retreat from enthusiasm and propose that the unfortunate ROM finally be left in peace. Attempts to replace it generate a lot of problems. Not everyone is able to do this do. The ROMABLE system is good as an option, but nothing more. Screen is much more interesting. We know that the ZX screen is 6 kb. There is still 10 kb. An ideal place to place what in the working version we will call ZX Runtime kernel. Its main function is to connect program segments with each other. A kind of nanocore. The programmer should not care about the actual locationsegments in pages. The pages are absolutely identical to each other. ZRK machine dependent because she will have to know what pages the machine has and how switch them. You will also have to contain some legacy system SOS variables that change their value based on interrupts (probably something can be relocated by changing IY) and the stack (at least the initial one). Here you also need to introduce the concept of BFI - Binary file interpreter (for those familiar with UNIX is a functional analogue of ELF Interpreter). Its task is to download the binary, together with ZRK, distribute it into segments and create a table of connections - what the logical program segment corresponds to which physical page. By the way it makes no difference whether you assemble a program from one or a bunch of files, so you can load it and implement load-time libraries, like .dll on Windows and .so on Linux - the load cost will be zero. Next, BFI can safely launch loaded code and cease to exist. From a program ZRK can be called explicitly or implicitly: 1. Implicitly - when making an intersegment transition (far call) from one paged segment into another or accessing data from one Paged segment, located in another Paged segment (not recommended practice because the brake, although in some cases this can be sacrificed for simplicity).2. Explicitly - if necessary, provide direct access to data in any of the paged segments. In this case, the page simply switches and that's all. Of course, most often such calls will be made from Resident Area. In C, it could basically look like this: [code] #pragma resident // Declare Resident segment void main(void) { SetPage(__selectmode); // Set up the segment containing the data memcpy(0x4000, initscreen, 6192); // The data was a picture SelectGameMode(); // This is a simple call - the segment is already enabled, the compiler monitors this } #pragma paged("selectmode") // Named paged segment, symbol __selectmode generated by the linker from the segment name char initscreen[] = {...}; // well, you understand - this is the image data void SelectGameMode(void) { char m; m = getch(); switch (m) { case 's': StartGame(); break; case 'j': SetupJoystick(); // And this is an example of FAR CALL. The compiler itself must take care of installing the required page and the same upon return. break; case 'k': SetupKeyboard(); break; } } #pragma paged("setups") // Another paged segment, we put everything into it settings void SetupJoystick(void) { // Here we select the joystick type } void SetupKeyboard(void) { // Here we assign keys }#pragma physicalpage(#07,"screen2") // And here we simply defined __screen2, which we will need in order to use the shadow screen. I think that if there was a desire, it would be possible to rework IS-DOS for such memory allocation. IS-DOS is an excellent system, but it contains serious conceptual error - it is simply not designed to be used paged memory by applications. The OS should occupy the bottom memory, not the top. At the same time, it must be modular (IS-DOS has this, but a module cannot dynamically throw it out of the system and stuff what I need in its place). A the concept I propose, coupled with the implementation of assembling a program from several files at the loading stage (load-time-linking) will solve a ton of problems. Each program, when loaded, will actually assemble its own OS for itself (to do this, it is enough for the head module to indicate that for it to work, for example You need a driver to work with the disk, a mouse driver and a printer driver. If This is a graphical editor - you can also request a GUI window system. If terminal emulator - modem driver and text console. Super mega killer demo will generally do without all this and will be able to work on its own using only switching pages from ZRK. Unfortunately, some memory manager extensions do not fit here.(for example, Profi's ability to change the projection window from 0xC000 to 0x4000, but this will have to be sacrificed for standardization. If it is subject use, then only machine-dependent modules for internal needs. But the second generation memory managers (to which I can only include ATM-Turbo with its ability to switch all memory) you can just find multitasking applications. Within such a structure one can distinguish virtual machines in which various programs will run. The only one The question of split screen remains - this needs to be worked out somehow. Such a scheme can provide compatibility with classic SOS, TR-DOS and IS-DOS applications. With IS-DOS everything is simple, you need to drag the ZRK as high as possible in memory (but not climbing behind 0xC000 - there are all sorts of electronic disks and other nonsense), write API RST#10 emulator - and you're done. What was the IS-DOS-48kb kernel is in the upper pages, access via ZRK (sorry fans of RAM disks, this is the 21st century, get screws). TR-DOS is even worse - as a rule, there is no way out of its applications. Actually, in As the simplest solution, we can recall Windows 95 with its option "Run in MS-DOS mode." When you try to run such a program, first a warning appears that you will have to leave any environment. WhenIf the answer is yes, Windows simply unloads, leaving the program to run in pure MS-DOS. Plus one more thing - TR-DOS programs with additional loads can be launched only from TR-DOS floppy disks. That's it, I started with the concept of next generation software and ended with a description prototype of the next OS concept. Although apparently one is not different from the other separable. By the way, what if we take IS-DOS and rework it according to this principle? As far as I understand, its sources are available? Although, of course, you can write prototype running on top of TR-DOS...