Retro Z80 project: Memory Layout and software management - Page 1
Forum section: electronics / general

author: obiwanjacobi
author_rank: Super Contributor
timestamp: December 12, 2015, 09:27:10 am
content: I have been thinking how to organize the memory for my Z80 computer project. I want to be able to address more than the 64k the 16 address lines the Z80 can handle. I know about memory bank switching and how to get that going in hardware - no problem (so, please don't go there).There are two aspects I am uncertain about:How to incorporate video memory "without" contention.How to organize the software to be able to use the multiple memory bank efficiently.I would really appreciate any suggestions you might have.Video MemoryThe main issue I am trying to solve is memory contention between the VGA controller and the CPU. I know about two/dual-ported memory but that is really expensive. I also know that FPGA usually also have dual-ported memory blocks, but that may not be enough - depending on the size of the FPGA.I could think of two alternatives for solving this:1) Have (more) smaller chips that can be addressed individually by the CPU and VGA controller. The granularity of the contention is now the memory size of the chips. A sort of poor man's dual ported memory bank. Down side is you need more chips/more board space and and more support logic (latches) to manage access to the individual chips.Also: you still need a way to pause the CPU on the spot when you detect an addressing conflict.2) Use double buffered video memory. This is pretty easy on the hardware side (I think). Have two identical parallel video memory banks and swap them between the CPU and the VGA controller - each only accessing one of them.The problem here is that after a bank swap, the CPU is presented with the old (previous) memory content of the video buffer. I haven't worked out how to deal with that.Software BIOSThe idea is to write a small BIOS for the retro computer that contains the system/service routines for interacting with the hardware. Some sort of memory manager will probably be in there as well.Question for the software is how do you deal with a broken up memory address space? You don't want to swap out the memory bank that contains the SP. And how do you run programs that are bigger than the bank size? How do you jump from one (parallel) bank to another and execute code there?I figured that this problem would have been solved before, but although there are plenty of hardware related resources to be found, I could not find any software BIOS/OS related ones.PS: Attached a blog post I am working on to organize my thoughts. Its a little more detailed if you want more reading...

author: nctnico
author_rank: Super Contributor
timestamp: December 12, 2015, 10:02:44 am
content: I'd look for an FPGA implementation of the Yamaha VG9938 or VG9958 video controller so you have a graphics controller which can do a lot of stuff on it's own (like drawing lines, copying pieces of image memory, sprites, etc) and has it's own video memory (Some DRAM or SRAM). A cool extension would be to add a background plane in which each video line can have it's own background color. That way you can create the sky-like backgrounds which made the Commodore Amiga games look so cool.

author: SeanB
author_rank: Super Contributor
timestamp: December 12, 2015, 10:46:20 am
content: How about using the clock phase to do the RAM access, only downside is the video ram will have to be a lot faster than the CPU, to handle the possible 2 sequential access cycles on the bits. CPU has the ram at high clock, and on low clock the video output can get it as the CPU does not need that bus, though you might have to use transparent latches on the CPU side of the data bus to latch the state for the slow CPU to read it when reading video ram.Fast SRAM is available these days as cache memory, so will easily run with a 5MHz CPU clock.Bios you probably will want a shadow RAM block for it, so at power up the first thing the CPU does is copy the ROM into a small block of RAM, then runs from the RAM only. Then use a 32k bank for your extended memory, makes it big ( half the CPU address space) and easy to do the remap for the applications to have some memory so they do not have to swap too much. Probably designate 16k for the bios/stack/interrupt tables/cpu register use space and 16k for a parameter pass block in the unswapped 32k, so you can do larger programs without the switching getting too bloated in code.

author: nctnico
author_rank: Super Contributor
timestamp: December 12, 2015, 11:39:37 am
content: BTW: The Z80 based MSX2 (and later versions) home computers had all these issues solved. There is a ton of information about these on internet! There is at least one full FPGA implementation of an MSX2.

author: legacy
author_rank: Super Contributor
timestamp: December 12, 2015, 11:55:06 am
content: Quote from: nctnico on December 12, 2015, 10:02:44 amhave you found a good one written in VHDL ?I have here a partial project, made in Eagle/CAD, I tried to realize a little PCB with a VG9958 chip plus 4-6 DRAMsstill to be completed

author: obiwanjacobi
author_rank: Super Contributor
timestamp: December 12, 2015, 12:10:15 pm
content: I have considered to have a functional graphics interface - use (vectored?) graphics routines to draw the screen instead of bit/byte access. I can see the advantages using that but I think you need a lot of routines (background, sprites, drawing, filling etc.) to make it any good. I am just starting with FPGAs so that may be a 'bridge too far'. I thought starting with a shared video memory design would be simpler, maybe not...?Using clock-phase: For now I ordered some 20ns 64k SRAM chips for my 20MHz CPU!- but that is intended for normal memory. I don't think they will be fast enough to do the clock-phase trick. But I like the idea - not sure if I can pull it off though... I have stayed away from (S)DRAM mainly because I don't know the details and it would complicate the design - I think. I am sure that if you know how that works you would argue it is not too hard. But the thought did occur to (re)use some old(er) PC memory package. But that would certainly require a FPGA to control the access to the module.Shadow ROM: what would be the benefit of copying the ROM to RAM? Why not simply map the ROM into the address space you want it? I know CP/M want RAM at the lower addresses - where normally the ROM would be - but that could be a specific mode you could switch to.I was planning on having 16k banks and a switching mechanism that would allow any block to be mapped to any address (16k boundary). But I can see that bigger blocks would have advantages. A parameter pass block was one of the things I was still struggling with. I wanted to keep the overhead as small as possible so I thought in the lines of RST instructions and using the SP for information exchange. There are several ways to pass parameters to a RST call. Pointing to a parameter block could be one of them.I thought BUSREQ would be to slow to respond? Zilog: "The maximum time for the CPU to respond to a bus request is the length of a machine cycle" which could be 3 (or 4?) clock cycles...? My thought was to simply halt the clock to the CPU - a trick I know some other design use as well. I would not want the screen to go blank. So the idea is that the VGA controller takes precedence over the CPU. I am currently thinking of doing 640x480x1 60Hz with a hardware color palette. I hope to get it up to 800x600x1 60Hz (/w palette) when I have a grasp on the FPGA stuff some more...

author: obiwanjacobi
author_rank: Super Contributor
timestamp: December 12, 2015, 12:17:13 pm
content: MSX2: Hmm good point. I was trying to remember what old home computers did use the Z80. I did look at some other designs but I could not find much information on how the software was structured. Thanx.

author: nctnico
author_rank: Super Contributor
timestamp: December 12, 2015, 12:20:22 pm
content: The VG9938 is pretty simple to program. I did that when I was 16 years old in assembly.If you want to go the shared memory route then using the WAIT pin on the Z80 is the way to go in order to stall a CPU memory fetch. Still I think you will be better off creating some kind of video controller which is attached to the IO bus of the Z80. You could have something simple like an address register (auto incremented) and a data read/write port. Using the WAIT pin you can synchronise accesses to the video RAM for the Z80 and video output. The easiest way is to create time slices in the video controller so you have a fixed division of time between Z80 access and video output access. I have used this trick in several of my TFT conversions for old equipment. Usually half the memory transactions is for writing data and the other half for reading data for the TFT display.

author: SeanB
author_rank: Super Contributor
timestamp: December 12, 2015, 12:27:38 pm
content: Shadow ROM is simply so you can use the RAM routines and overwrite them if needed, plus most older ROM devices are pretty slow compared to RAM. It just needs a routine on startup to copy the 16k of ROM to the 16k of higher RAM, then jump there and use an IO register to switch the banks ( could even be a bit in your bank switching so you can get it back without a reset) then copy down to low memory, probably omitting the copy routine or decompressing a larger block to fill the code space with extra routines, then initialise the code there, drop back down to the low quarter then clear the upper 16k and start a monitor program or load in other bank switched ROM as needed.

author: obiwanjacobi
author_rank: Super Contributor
timestamp: December 12, 2015, 12:55:40 pm
content: Yes, doing IO for drawing sounds really attractive - depending on the capabilities of the graphics controller chip. It would pretty much eliminate the contention problem. I did not get all of what you (nctnico) wrote. I would think that simply using a couple of IO port addresses would be all that is needed. No wait states, address counters or whatever (use something like OTIR?). The video memory would be private to the VGA/graphics controller...?Ok shadow ROM was to get around slow ROM chips mainly then..? I do not want self-modifying ROM codeI think I might do something like this in the end but I would disallow writing to the ROM addresses in hardware after it has been loaded (as described in the attachment #1).

author: BloodyCactus
author_rank: Frequent Contributor
timestamp: December 12, 2015, 01:52:48 pm
content: for my little z80 project I'm using a PIC acting as mmu, 5v tolerant which is nice. for video I've got a bunch of NOS pc ramdac chips, for ram I got some NOS dual port ram from ebay for $4. in theory I should be able to to the dual port VRAM to the RAMDAC and get a decent vga display. the ramdac chips are pretty sweet.ebay title for the ram"8× TC524258BZ-80 DUAL-PORT VIDEO RAM 256Kx4/512x4 150/30ns 5V ZIP?28 DRAM VRAM""8× uPD41264C DUAL?PORT VIDEO RAM 64Kx4/256x4 155/40ns 5V 0.4" DIP-24 DRAM VRAM"the same guy who has the ram 'exdwh' also has some ramdacs, not as many types as he used to have but$1 for 5? 170mhz, 5v tolerant!"5× TI TLC34076 ENHANCED RAMDAC PALETTE 256/16M 24-BIT 170MHz 5V PLCC-84 SMD SMT"looking at TI's page for that chip, its pretty sweethttp://www.ti.com/product/tlc34076

author: Howardlong
author_rank: Super Contributor
timestamp: December 12, 2015, 02:22:50 pm
content: Dual port RAM for the video would be my choice too, it'll save the need for multiplexers and complexing timing or CPU stalls (unless you want to put up with "snow" - remember that?).I used a parallel nvSRAM many, many years ago circa 1993 on a my last Z80 design, it saved on chip count in a wearable device - amazing to think I was doing a wearable device before the term was even coined. These were made by Simtek, now taken over by Cypress. They take the shadow ROM and automatically load the SRAM at power up. Similarly at power down they can optionally save back to ROM at power down using a reservoir cap. Also because it's SRAM, it's fast, 25ns or so. Looks like they might even still have a 5v version.http://www.cypress.com/file/124951/download

author: Stray Electron
author_rank: Super Contributor
timestamp: December 12, 2015, 02:52:39 pm
content: Have you considered using a Hitachi HD-64180? It will easily handle more then 64k of memory. You might want to take a look at the design that Steve Ciarcia did in his Circuit Cellar column in BYTE magazine. I built two of them back in the day and it was an excellent design. Software and CP/M OS should still be available.

author: daybyter
author_rank: Frequent Contributor
timestamp: December 12, 2015, 02:54:26 pm
content: ez80 has a 16 MB memory mode

author: obiwanjacobi
author_rank: Super Contributor
timestamp: December 12, 2015, 03:40:05 pm
content: I must not understand how these dual ported memories work. The ones I have found had two distinct address and data buses (and were 50,=). These chips have only one parallel (two-phase row/col) address bus as far as I can see. I don't see how to specify a separate address for the serial data retrieval - which is an excellent idea for a VGA controller. And they are cheap(er) indeed - although shipping adds a bit (I am not in the US)...No, I want to use the Z80, although the eZ80 looks really nice.Any thoughts on the double buffered video memory approach?

author: legacy
author_rank: Super Contributor
timestamp: December 12, 2015, 03:51:38 pm
content: does anyone want to complete ore reuse my PCB project about Yamaha VDU chip ?I haven't written the assembly part yet, and in case, I'd like to write 68k codebtw, about VDU, has anyone seen good VHDL around ? (OpenCore is full of …)

author: legacy
author_rank: Super Contributor
timestamp: December 12, 2015, 04:03:54 pm
content: another point: V99xx is usually compliant with RGB+H&Vso a real V99xx chip needs a RGB+H&V crt, or an LCD adapted to such a synchronism, in first placemy 50 cent

author: nctnico
author_rank: Super Contributor
timestamp: December 12, 2015, 04:39:43 pm
content: The beauty of an FPGA implementation is that you can easely adapt it to whatever purpose you want. I wouldn't be surprised if the VG99x8 implementations can already drive VGA.

author: legacy
author_rank: Super Contributor
timestamp: December 12, 2015, 05:51:01 pm
content: I have written a simple VDU, in vhdl, VGA driven, but it's text console oriented, with hardware support but it comes with no graph engine

author: C
author_rank: Super Contributor
timestamp: December 12, 2015, 06:32:15 pm
content: If you are not going to use a dual port memory chip then timing becomes important.The display needs the memory when it needs it to prevent video glitches.The simple thing is to have the Z80 waiting for a time slot to video memory. When the switch to Z80 buss happens you need to recreate a memory cycle to video memory. You delay /MREQ a little to let the address buss get stable to video memory after buss switch. You delay the /RD & /WR signals a little more so that address buss and data buss is stable to video memory before read or write happens.For a Z80 write you could latch the incoming data buss so it is stable for video memory. For Z80 reads you could latch output of video memory so that Z80 data buss remains stable for Z80 to read.Using the Z80 wait input adds big delays. Stretching the Z80 clock signal would allow smaller delays. This clock stretch circuit could also be used to stretch timing for other buss operations.With shadow memory you can read from ram and write to ram & video memory. The reads would not be delayed.Z80 memoryNeed something to look at memory map wise.At first look, this looks ok for a Z80 but has problems.If you use the RST instructions you have problems with lower memory changing from bank to bank.You have RST instructions that can happen at any time. You also have /INT & /NMIOne easy to do thing is to use memory layers.You could have some memory decoding happening directly connected to Z80.A decoder for the first 256 bytes of Z80 memory is easy. When the Z80 access this range of memory use this decoder to enable common 0-255 memory AND disable all other memory decode. You would be creating an "I AM ACCESSED" signal. Banks or expanded memory only respond then there is no "I AM ACCESSED"You could use the "I AM ACCESSED" idea to create many layers that happen before allowing the expanded memory to respond.One Instruction to look at is the OUT C,A instruction.The address buss has the contents of the B & C registers with the register A on data buss.Use Register C on A0-A7 & /IORQ to creates a chip select.Use Register B on A8-A15 for lower addresses for a very fast ram chip.Use Register A on data bus for data port of very fast ram chip.You can find very fast 256Kx8 memory chips. You use one of these to create an expanded memory address buss.One problem with creating small memory areas is the amount of data needed to switch banks.The Idea is to setup the data in this high speed ram chip one time and then use an additional I/O port control the upper address lines to very fast ram chip. This I/O port would switch the Z80 memory map by using a different area in this ram chip.Using 4 bits of this ram output to replace 4 bits of the Z80 high address would give you 4K blocks of memory and leave 4 bits to expand the Z80 address range. The problem is the 16 writes needed when changing the map. If you use a second I/O memory port to control the higher address lines off this ram chip, then you could have 256 different memory maps. Your bank switch becomes one I/O write selecting which memory map to use.Look at the bank picture again, the 0-255 decoder keeps this chunk of memory the same all the time.To have memory the same as picture, you would setup four memory maps. To change maps is one I/O write.To make it easy add one more column to the left and call it "POWER UP BOOT MAP". Power up clears a FF which disables all mapping by using "I AM ACCESSED" signal. This FF could also enable a low default on all expanded address lines. On power up the Z80 would see the bottom 64k of the expanded memory.Large linear memory would make it easy to use the current memory chips. You could have many maps to access large video memory and normal memory.Adding a second high speed cache ram chip like above would add 8 more bits to address buss at little cost.The Z80's 16 bit address buss + the 8 from second fast ram chip = 24 bit address buss. Add the four from first ram chip and you have 28 bit address buss with mapping in 4k blocks that is very fast to change mapping.C

author: Bruce Abbott
author_rank: Frequent Contributor
timestamp: December 12, 2015, 07:22:04 pm
content: Quote from: obiwanjacobi on December 12, 2015, 12:10:15 pmWhat do you want to use it for? Vector graphics are good for CAD and wireframe animation, but not much else. Sprites are good for games. Bitmaps are good for general purpose graphics, but slower for vectors and sprites.QuoteYou could have the VGA controller access RAM in larger chunks eg. 32 bits which leaves 3 out of every 4 slots free for CPU access. Contention can be eliminated by adding waits states to the CPU when required, which will only slow it down a little.QuoteShadowing the ROM allows you to use a slower EEPROM for booting and still have full-speed operation.QuoteTake a look at the Amstrad CPC architecture. It splits memory into 16k pages and 64k banks which can be combined in various ways. You can have two memory blocks (RAM or ROM) mapped to the same address, reading from one and writing to the other. Calling between banks is performed via kernal routines which ensure that the correct memories are switched in.QuoteWhat does the 'x1' mean - 1 byte per pixel (256 colors)?

author: legacy
author_rank: Super Contributor
timestamp: December 12, 2015, 10:37:51 pm
content: thisVDU emulator seems interesting, as implementation ideas

author: westfw
author_rank: Super Contributor
timestamp: December 12, 2015, 11:33:50 pm
content: QuoteWell, THAT'S not very retro anymore!You might want to look at how the various newer z80-like chips do their bank switching and do something somewhat compatible.That would include the newer Zilog chips, and the renesas 78k and rl78, I think.(You know, I never liked being limited to 64k, but I spent a lot of time thinking that 16MB (24bit address) would be enough for almost anything (possibly adding MMU to allow for multiple 16MB address spaces.) An RPi0 with 512MB hidden inside the CPU package somewhere is just ... mind boggling.)

author: Ian.M
author_rank: Super Contributor
timestamp: December 13, 2015, 12:05:00 am
content: IMHO, if you are going to build a banked Z80, go for 4K blocks, with separate read and write mapping. The finer granularity is a considerable benefit if you are working with large data sets as you can map as much as 60K for data. By making the write mapping separate, you can write-protect blocks of RAM by write mapping them to nothing or ROM. The overhead to set up the mapping isn't too high if you decode 16 bit I/O addresses such that two of the address lines select whether the read map or the write map is updated, allowing both to be updated simultaneously if desired.

author: BloodyCactus
author_rank: Frequent Contributor
timestamp: December 13, 2015, 01:33:02 am
content: 4k is pretty big when the cpu can only see 64kb. its big if you implement cpm too. 1 or 2k paging works better.

author: Ian.M
author_rank: Super Contributor
timestamp: December 13, 2015, 02:03:40 am
content: If you go smaller there are too many page registers to write to remap stuff. 4K is tolerably convenient as you only need 32 bytes of dual port RAM )or RAM with separate Din and Dout at some cost in the complexity of the I/O mapped load circuit)to implement full independent read/write remapping of a 1MB address space, and done right, you can remap the whole 64K using OTDR to load the mapping table in 331 T cycles (Use the B register that appears on A8:15 to address which page register to update, and C on A0:7, decoded to three addresses for update write mode, read mode or both together.) If you've got a larger dual port RAM, you can implement multiple maps you can 'flip' between. Startup requires disabling the mapping after Reset so it can execute from ROM until a particular I/O address is touched to give the startup code a chance to load the map.

author: obiwanjacobi
author_rank: Super Contributor
timestamp: December 13, 2015, 09:03:56 am
content: @C:thanx!I don't like to reissue the the CPU memreq - sounds all very complicated. Thanx for bringing this to my attention, I did not realize it until now.If I understand you correctly then the 'very fast ram chip' is only used to translate an IO operation (OUT C,A) into an extended memory address (A16 and higher). Why would you need 256kx8 for that? I must say I don't think I got everything you are trying to tell me here... sorry.@Bruce Abbott: Vectored graphics was just a brain fart. I though it would be cool to be able to scale stuff easily. I am thinking of doing three display modes: 1) character mode (simple to start with), 2) VGA graphics mode, 3) hi res monochrome mode.I like the idea of using a different data bus width on the VGA side, although I don't see how you can let the CPU access the other bytes in the meantime. To my mind it would simply mean that the VGA controller is done sooner.Yes, the 'x1' is one data byte for indexing the palette. The palette can be whatever color-depth you want (24 would be nice)@Ian.M: I am confused. One says use big blocks (32k), you say use smaller blocks (4k), another says go even smaller (1k/2k)... So with these smaller blocks you're going to have to maintain page tables for each program, right? - in order to make sure that they all 'stay together'. What would be the benefit of that if the CPU does not support extended addresses natively like in the x86 and the first PC architectures (segmented/paged/virtual memory)? I can only think of more efficient memory usage at the cost of a more complex management. Is that the purpose?I have been thinking a little more on using a double buffered video memory. While it is excellent from a hardware perspective because it would practically eliminate contention, from a software perspective it is not so good. It would require the software to redraw the entire display in the video memory each time (because after the memory is swapped it contains the previous scene) it wants to change something. It may not be a problem but it feels sub-optimal. It would take extra time and memory and add program (or bios) complexity.Can someone explain to me howthese dual port chipswork? And if the 150ns/40ns is fast enough for a 20MHz clock?

author: bitslice
author_rank: Frequent Contributor
timestamp: December 13, 2015, 06:04:20 pm
content: Quote from: obiwanjacobi on December 12, 2015, 09:27:10 amHas anyone used the 74LS610 memory mapping chips?Personally for a Z80 design, I'd be taking advantage of the Z80 DMA chip to communicate with a video display.Maybe offload graphics commands to a separate processor running a v9958.One could blat out graphic primitives from the Z80 via a FIFO, so the DMA chip was occupying the bus for as little time as possible.

author: C
author_rank: Super Contributor
timestamp: December 13, 2015, 06:24:16 pm
content: Back in the 80's radio shack /tandy produced two lines of computersThe TRS-80 model 1 seriesYou had the Model I, Model III, Model IV, Model 4PAll have dual port video memoryThe Model I & Model III used logic to create video out.The Model IV & Model 4P used a 6845 80x24 is hard to do in logic, with a 6845 it is a lot easer.All could have a memory map starting a 0 of 12k rom, 4k I/O(video & keyboard in here), 48k ram.The 4 & 4P could change memory map to run CP/M and had option for 128k.The 4P did not have the 12k rom and instead loaded a disk file to act like a rom.Some of these used 16kx1 dram so 3x8 chips. when 64lx1 cost dropped was cheaper to use 64K chips and not use 16kCheap low cost logic used in these with pal's used in later versions.The model II seriesModel II, Model 12The Model 16b was a model II with added cards containing a 68000.The Model 6000 was a Model 12 with 68000 cards.These were built using the add on Z80 chips( dma, sio, pio ).Used a card cage to add more boards and could have added memory boards.Not a down to a cost system.http://www.classiccmp.org/cpmarchives/trs80/Library/Manuals/Hardware/The Service Manual or Technical Reference Manual shows the circuits and describe how the sections work.The LOBO MAX-80 could run most Model III & Model IV software and CP/M-3.128k ram, 4 x 5.25" floppies, 4x 8" floppies. (single or double sided and single or double density). SCSI-1 interface. Only one rom in system the 512 byte boot rom.A ram chip was used instead of a character rom, so a second block of dual port memory.The manual for this talks about using the Z80 with a banked memory.A little reading of above could save you a lot of time and help you build something better.The 6845 data sheet is not bad about explaining character based video and even using this chip for graphics displays. Newer designs use a micro controller or fpga.Fixing the timing of signals like /MREQ is not hard. Putting a signal through two inverters in series gives you a time delay. There are time delay chips where you have taps that have a fixed delay. You can also use clocked logic to do this.In the dynamic ram examples There is a 2 to 1 buss switch on address lines while generating new /mreq delayed signals(/ras,mux,/cas). If you look at examples using the 64kx1 dram you will see a switch on A7 to extend Z80's 7-bit refresh address to 8-bits.When you add bank switched memory or a memory mapper, both take time to function. The greater the delay the faster the down stream memory speed to keep the Z80 at same speed.The 256kx8 chip is cheap & fast. nothing says you need to use all the space.To have 32k blocks of memory you are replacing the Z80's A15 with a new version. with one 8 bit output port you could have 4 bits to specify the address of the lower 32k of memory and 4 bits to specify the address of the upper 32k of memory. This would let you have 32k blocks from 512k of memory. To this you would need to add a way to have some common memory. You could use two 8 bit output ports and you would gain 4 more bits for addressing at the cost of one I/O writes to change both banks. The Z80's A15 would be controlling a 2 to 1 switch like the 157. This adds two chips for one 8-bit port and four for the two 8-bit ports. You would be adding the 157's time delay for switching inputs to the Z80's memory access time.If you change to 16k blocks you need more output ports and need to use a 4 to 1 switch.With 8k blocks a 8 to 1 and with 4k blocks a 16 to 1 (74150) switch.More and more chips are needed.The ram chip is the 8-bit output ports and the 16 x 1 switch in one package.The difference is the time delay of the 16 to 1 vs ram delay and saving a lot of chips.Now in place of using a small ram for this you can use a larger ram. You could strap the extra address lines making large ram small or you could connect these to a 8 bit latch. This 8 bit port could switch between 1 of 256 different memory maps with one I/O output. Changing between banks like in picture is just one I/O output.On power up you could load this ram one time. To get a 4k common at top of memory you just make the same entry for that block in each map.You have one very fast ram. One 244 to connect the Z80 data buss to the data inputs of the ram chip while loading the maps. Using /IORQ to write the map prevents the expanded memory from responding as expanded memory uses /MREQ.On power up the contents of this ram is unknown. If power-up prevents ram /OE and ram data lines have pull-up resistors, the first 4k of the Z80's memory will be mapped to the highest 4k of expanded memory.To increase the expanded memory by 8-bits would require one additional very fast ram chip and small change while loading maps.

author: C
author_rank: Super Contributor
timestamp: December 14, 2015, 08:40:12 am
content: Reading some of your thoughts in Z80 Memory, some of the problems are not easy to fix.While a user program is running on a Z80 the user program has access to all it knows about or can find out. Easy for a user program wrong.The 68000 that was designed with multi-users, multi-tasking & many 68000's on a buss could still get in trouble that the processor could not work around. The cure was to have a second 68000 fix the problem. The 68010 fixed the need for a second processor fix and added the capability to run virtual 68010s.You might want to think of two z80's, one for the user and second for the system.There was an operating system called TurboDos that could run most CP/M programs. Unlike Digital Research's MP/M that tried to put many users on one Z80, TurboDos gave each user a Z80. Their could be many Z80s on a buss and/or networked to more. The simplest user Z80 was a Z80 card with memory that plugged into a system buss. Most added a simple interface to improve communications with other Z80s. Another Z80 on the system buss would load the initial program into ram and then release the Z80 Reset. The manuals and software are on the net. The bios interface is described in the manual. It is a very simple and powerful.Remember that hardware designs you find on net are around the Z80A or Z80B( 6Mhz) and will need to be adjusted as Z80 clock speed is increased. Logic timing becomes very important. Good practice is to buffer signals going off board. The Address buss & data buss would each have two buffers adding a time delay. Consider the time needed for a memory read of memory on a second board

author: grumpydoc
author_rank: Super Contributor
timestamp: December 14, 2015, 09:45:36 am
content: A 20MHz Z80 has been mentionedBut, apart from "VGA" not much regarding what graphics is intended.Are you aiming at 640x480x16 colours or would you be happy with less resolution?Have you a graphics controller in mind?The MSX graphic chips (yamaha 9938 & 9958) have been mentioned - probably a good solution but the video RAM is not shared between CPU and graphics. Was achieving shared memory important to your design?

author: westfw
author_rank: Super Contributor
timestamp: December 14, 2015, 09:50:05 am
content: QuoteThere's a big difference between implementing a bank-switching scheme typical of the z80 era of computing, and implementing some sort of "real" paging/segmentation scheme.The OP needs to figure out which they're doing.I don't think that there are too many examples of fancy z80 memory management schemes (not counting the "modern z80s" that I already mentioned), because by the time it was practical to put more than 64k of RAM on a system, there were cpu chips that directly addressed more than 64k of memory. The original IBM-PC shipped with as little as 16k of RAM, even though the 8088 could address 1MB, and the 68000/68010 (addressing 16MB) was available in the same timeframe. (And the Z8000, too, I guess, but it flopped?)You could look at whatever MP/M did, although it was a lot less popular than CP/M (which had very minimal support for memory beyond 64k.)

author: obiwanjacobi
author_rank: Super Contributor
timestamp: December 14, 2015, 11:16:12 am
content: @C: I am planning to write a bios that contains basic service routines to work with the hardware. The user program does not have to be isolated and can use the bios to perform video output and memory bank switching (details not yet understood).The higher speed is indeed a point of focus. I carefully picked out my sram chips to be fast enough. That is also why I do not want too many glue-logic chips.I am also trying to understand FPGAs (VHDL) because the initial idea was to write the VGA controller (memory dumps) in a FPGA. Any glue logic will probably also be housed in the FPGA (should be fast enough). I envision the main board with the FPGA, Z80 CPU and some core mem. Then a central bus to extend and connect external modules (stacked pcbs). But nothing is set in stone except using the Z80. I aim to make a blend between the retro z80 software experience and modern hardware. I don't need to be period correct on every aspect.@grumpydoc:- The aim for VGA is indeed 640x480x1 byte that indexes a color palette.- Whether to use shared video memory or a graphics controller is not decided yet. I initially dismissed a graphics controller but this thread made me rethink. No specific controller in mind (although I saw the new FTDI EVE2 chips recently...)- Shared memory is not mandatory in this design - although I would get a kick out of it when I get it to work. > 64k is part of the design.@westfw: I was aiming for the typical Z80 retro type of memory management. Not the 'modern' segmented/paged/virtual memory management type.

author: Ian.M
author_rank: Super Contributor
timestamp: December 14, 2015, 12:53:33 pm
content: A brief historical review may help you find Z80 systems worth studying:Later generation MSX systems had fairly fancy memory management and could run CP/M, I understand MSX was reasonably popular for a time in the Netherlands.On the cheap side, the Sinclair (Amstrad) Spectrum +2A and +3 had limited 16K block paging, out of a pool of 128K RAM and 64K ROM, just sufficient to support CP/M+ with an 11K RAMDISK and 61K for user programs.The Amstrad PCW512 (another CP/M+ machine) had 512K RAM and 48K ROM, again with a 16K block size, but with the capability to map reads ad writes to different pages.The PCW512 might be a good starting point for a 'compatibility' mode to run CP/M+ and access a wide range of development tools (of dubious legality).On the subject of RAM and paging: i80486 era cache RAM is still reasonably readily available. A typical example being the Winbond W24257A 32Kx8 high speed SRAM, which came in speed grades between 10ns and 20ns. 12ns and 15ns grades are still findable. It has 15 address lines and can be used with /OE and /CS held low, which will give a propagation delay from address line change to valid data out of no worse than the speed grade. If a W24257A was inserted between the high 4 bits of the Z80 address bus (to 4 of its address lines) and the high 8 bits of a 20 bit memory address bus (from the W24357A data bus), with a fast address decoder and lets say 512K or 768K of comparable speed 128Kx8 SRAM, (e.g.ISSI IS61C1024which can still be found N.O.S. in PDIP), you could comfortably meet the worst case 80ns cycle time of a 12MHz Z80, which IIRC, was the fastest pin-compatibles went.One more W24257A address line would be used to implement separate wriite and read paging, driven by the Z80 /RD signal, which is valid much sooner than /WR. Ground two of the remaining address lines for simplicity and connect the rest to an I/O mapped 8 bit latch to permit instant swapping between 256 complete page tables. You'd need a tristate bidirectional buffer linking the Z80 data bus to the high 8 bits of the memory address bus to permit the W24257A to be read or written in the I/O space, and an 8 bit latch for I/O operations to select the page table to access without smashing the current memory page table selection, + some glue logic to decode a single 8 bit I/O address, connect the read/write table select address line back to A8 , swap A15 down to A9 (so tables can be rapidly loaded with OTDR) and handle the W24257A /RD, and /WR signals.. Use A15 set on that port to access the page table I/O operation latch. Finally, another 8 bit port would be decoded to access the memory operation page table select latch so page tables could be selected and activated with a simple OUT (port), A instruction.To permit bootup from ROM, A12:19 on the memory bus would have pullups and the W24257A /OE would be held high by a flipflop set on /RESET, and reset by the first access to the memory operation page table select latch. That would map the top 4K of the 1MB address space throughout the 64K address map, which would of course be the Boot ROM, running in RAMless mode, and its first job would be to set up a page table that mapped the ROM starting at address 0, and some RAM at 0x8000 upwards and activated it. From then on, normal Z80 operation with a stack in RAM and memory paging would occur.Due credit to user 'C' for essentially the same concept above, I've just refined it to use fast real-world parts and optimised some stuff like loading itDue to the swappable paging tables by a single OUT instruction, you can easily emulate any 'classic' Z80 system memory map and only have to patch the page selection code in your ripoff of that system's BIOS.However, I think you are making a massive amount of trouble for yourself compared to using an opcode compatible Z80 successor with a MMU like the Hitachi HD64180 or one of the Zilog Z180 family.

author: grumpydoc
author_rank: Super Contributor
timestamp: December 14, 2015, 03:48:10 pm
content: Quote from: Ian.M on December 14, 2015, 12:53:33 pmA 20MHz part was mentioned which will tighten up timings to 50nsIn any case, given the target of 640x480x8bits per pixel a pixel clock of 25.175MHZ is needed (standard VGA timing @ 60Hz). That means a 40ns cycle for the video. This could be reduced by making the video RAM more than 8 bits wide but given that one can get large fast SRAMs these days it might be possible or even easier not to bother.I suspect that the best way is to split the video clock into half for video system access and half for system access. That shrinks the cycle to 20ns unfortunately and we have to get some address multiplexing in there as well.Something like a Cypress CY7C1049D-10VXI would do for video RAM - 10ns 512k x 8bit. For multiplexing you could probably get away with 74AC157s as the typical propogation delays are around 5ns, leaving you "plenty" of time in the 20ns cycle. Worst case propagation delays might leave you feeling a bit blue though as they are > 10nsA 10ns part such as the Winbond should also be OK even at 20MHz as there's actually about half a clock of address set-up time before MREQ goes active.Mind you, with the timings as they are I don't think I fancy getting it all going on a breadboard

author: Ian.M
author_rank: Super Contributor
timestamp: December 14, 2015, 04:51:53 pm
content: You could shave a few ns by using low Rds_on analog switches for the glue logic to multiplex the page translator RAM's address lines between I/O access mode and memory address tranlation mode. That means that *AFTER* address translation, assuming a 10ns translation RAM you still have a 40ns cycle 'window' for the main memory. Using fast analog switches to multiplex the VRAM between the VGA controller and the memory bus could also shave some ns.However, it might be a better idea to design an AT ISA bus interface allowing ISA bus SVGA cards and other goodies like super I/O cards with IDE and FDC controllers to be used. It might need a wait state for the Z80 while accessing the 'slot' area but that would be a small penalty to pay for predictable contention-free timing and no need to build hairy high speed video circuits or to have to invest time and money in FPGA development tools.Stick an EIDE to SATA adapter on one of the super I/O card's IDE ports, and you should be able to hook up modern storage as well. The cards are getting a little rare nowadays, but they are still findable, and anything with Linux drivers can be assumed to have sufficiently well documented registers to be a candidate.

author: legacy
author_rank: Super Contributor
timestamp: December 15, 2015, 03:14:53 pm
content: someone wants help me with my text-VDU ? it's written in vhdl && almost working!someone interested in V99x* pcb with 4/6 DRAM ?if so, contact me in PM!

author: AlxDroidDev
author_rank: Frequent Contributor
timestamp: December 15, 2015, 08:25:16 pm
content: Quote from: Ian.M on December 14, 2015, 12:53:33 pmSince the MSX was my very first computer, back in 1988, it would be fun to have one.I have an used HD64180ZFS6X (6MHz), taken from a printer controller board. How hard do you think it is to build an MSX around this chip? It definitely looks like n interesting project, if feasible at all.

author: Bruce Abbott
author_rank: Frequent Contributor
timestamp: December 15, 2015, 11:22:35 pm
content: Quote from: AlxDroidDev on December 15, 2015, 08:25:16 pmMSX architecture is very simple so I think it could be done without much trouble. Undocumented instructions might be problem for any software that uses them.Some day I want to try out the HD64180 or Z180. So far I have made a simple SBC with CMOS Z80, 32k EEPROM, 32k static RAM, 16C550 serial and a breadboard for testing I/O chips. I have just tested an AY3-8910 (works perfectly!). Next up is AY-3-8912, 82C55, TMS9929 and V9958 (all purchased from eBay).

author: AlxDroidDev
author_rank: Frequent Contributor
timestamp: December 16, 2015, 01:02:59 am
content: Quote from: Bruce Abbott on December 15, 2015, 11:22:35 pmVery nice! Congrats!My HD64180 is a QFP-80, but that shouldn't be a problem. Properly etching a board with 80 perfect tiny pads is more complicated than doing all the soldering.Building a BIOS/CMOS and an EEPROM programmer shouldn't be a problem either, but I believe it is a requirement, right?What handles the keyboard IO in your SBC ?

author: jwm_
author_rank: Frequent Contributor
timestamp: December 16, 2015, 03:36:17 am
content: Have you considered helping things out with software since presumably you are writing your own BIOS? Have an interrupt every 60hz (or whatever your refresh is) that lets the CPU halt properly, bank out the video memory and then raise a line telling the ramdac to go do its thing. If you bank switch in and out the video ram via BIOS routines, you could even have the CPU carry on its normal program until something actually tries to switch in the video memory then pause until it is done so you will get a degree of concurrency in the common case.

author: Bruce Abbott
author_rank: Frequent Contributor
timestamp: December 16, 2015, 03:52:41 am
content: Quote from: AlxDroidDev on December 16, 2015, 01:02:59 amEPROM programmers are so cheap now I wouldn't bother building one. I use a MiniPro TL866CS, which goes for as little as US$45 oneBay. It does most (E)EPROMs, and also some PICs, AVRs, and GALs. I like using GALs during development to replace random logic gates (saves a lot of rewiring).QuoteKeyboard input is via the serial port. I just use Hyperterminal in Windows as my console. To interface to the PC I use a USB to TTL serial adapter (no point in converting to/from RS232 levels when you don't need to!). The driver is very simple. Here is all the code you need to drive a 16550 UART:-Code:; UART I/O port addressesuart_base equ $00;uart_register_0 equ uart_base + 0uart_register_1 equ uart_base + 1uart_register_2 equ uart_base + 2uart_register_3 equ uart_base + 3uart_register_4 equ uart_base + 4uart_register_5 equ uart_base + 5uart_register_6 equ uart_base + 6uart_register_7 equ uart_base + 7;--------------------------------------------------------------------------; Set UART to 9600 baud, 8 bits, no parity, 1 stop bit.;INITUART: ld a, $80 ; select baud rate registerout (uart_register_3), ald a, 12 ; baud rate low byte 1843200 / (16 * 9600)out (uart_register_0), ald a, 0 ; baud rate high byteout (uart_register_1), ald a, $03 ; select data register, 8N1out (uart_register_3), aret;------------------------------------------------------------------------------; Send character to serial port;TXA: push aftx_ready_loop in a, (uart_register_5)bit 5, ajr z, tx_ready_looppop afout (uart_register_0), aret;------------------------------------------------------------------------------; get character from serial port;RXA: in a, (uart_register_5)bit 0, ajr z, RXAin a, (uart_register_0)ret;------------------------------------------------------------------------------; Check to see if character is available;CKINCHAR: in a, (uart_register_5)bit 0, a ; NZ if char availableRETMy operating system is a slightly modified version ofGrant Searle's ROM BASIC. This has full source code so you can easily reconfigure it to suit your own hardware. The advantage of BASIC is that you can quickly do stuff like accessing I/O ports without having to compile and download code - just like we used to do 30 years ago!BASIC programs can be saved and loaded via text transfer in Hyperterminal. If I want to run a complex machine code program I burn it into the EEPROM (Winbond W27C512) which only takes a few seconds.

author: westfw
author_rank: Super Contributor
timestamp: December 16, 2015, 07:04:55 am
content: QuoteWhat are you using to create the GAL "binaries"? The modern CPLD/FPGA tools are huge (they make AS7 look compact!), and the versions of PALASM I've found seem to still use DOS 8.3 filenames and such...

author: bson
author_rank: Unknown
timestamp: December 16, 2015, 07:47:39 am
content: Quote from: obiwanjacobi on December 12, 2015, 09:27:10 amAbout $7 for 8 VRAM chips, shipped.http://www.ebay.com/itm/8-uPD41264C-DUAL-PORT-VIDEO-RAM-64Kx4-256x4-155-40ns-5V-0-4-DIP-24-DRAM-VRAM-/221594789095?hash=item33981424e7:m:mDXZfBiRIpdgA5b_TY1r5SAThe datasheet the seller links...http://exdwh.com/uPD41264C-12.pdfSerial access for video, random access for a CPU.Not entirely authentic though, quite a bit post-Z80...There are more variants on the same theme (parallel CPU bus, serial video port).Could probably have two of these fill the entire Z80 address space and use it as main memory. For ASCII character generation you'd need to clock the output into a 595 or other shift register and consider it byte wide and play around a little with the addressing.

author: grumpydoc
author_rank: Super Contributor
timestamp: December 16, 2015, 10:11:50 am
content: Quote from: bson on December 16, 2015, 07:47:39 amThe problem with the above is that they are a bit small - 64k x 4 - if you are aiming at VGA resolution; 640x480 x 8-bits per pixel is 300k of video RAM.You can get large, fast dual port RAM - eghttp://www.idt.com/document/dst/709099-datasheetbut I haven't found any 512k x 8 chips so you would need multiple packages and TQFP-100 isn't exactly a friendly format for DIY.I think contention-free access would just be possible with discreet parts using 10ns SRAMs and 74AC series logic as long as some care is taken over with timings, gate delays and probably layout (not sure it would work on protoboard).If I have chance I will try to put a few schematics and timing diagrams together.

author: Ian.M
author_rank: Super Contributor
timestamp: December 16, 2015, 11:19:23 am
content: The question should be: Is it worth implementing HiRes memory mapped 8 bit/pix video on a Z80 (or descendent) system.To do anything significant without hardware assistance is *SLOW*. Lets assume that for simplicity you only support VGA 640x480. That's 307200 bytes of RAM. Lets further assume a 20MHz clock speed and that one is using extensive loop unrolling e.g. large blocks of LDI instructions. LDI takes 16 T states. (a 5 T state saving from LDIR by loop unrolling) To move one screen will therefore take 4,915,200 T states + loop overhead, which comes out to 1/4 second just to scroll the screen.Unless you have a strong need for compatibility with a specific vintage Z80 system, this just doesn't make sense. Its Waltzing Bear territory. The system is obviously crying out for a powerful graphics coprocessor, but that will more than double the development effort required and make it much harder for anyone else wanting to follow the project to source the parts to do so.One possible answer is a hosted Z80 system. This has a long and honourable tradition behind it going back to the Apple IIZ80 SoftCard. Not only does it solve the graphics speed issue, it also provides bulk storage, easy cross-assembling/cross-compiling and if done right, no need for EPROMs, as the host can stuff the startup code into RAM before releasing the Z80 (or successor) reset line. If you put a large dual port RAM between the Z80 and the host, with a FPGA controlling it (with full access to all Z80 bus signals and a register interface to the host), you can do stuff like implement a NMI driven in-circuit debugger for the Z80 giving you single stepping and hardware breakpoints with very little Z80 code required in the monitor 'ROM', which can entirely be contained in the FPGA for minimum 'footprint' on the Z80 side.Host it off a full GUI capable Linux SBC, and write the graphics engine, storage engine and the bulk of the debugger to run on the host.I would also suggest giving the Z80 CPU card a 24 bit address bus (yes this involves page translation even on a Z180 card, but that can be done in the FPGA), lots of fast RAM and S100 Bus edge connector. Memory (and I/O) mapping the S100 bus would be handled in the FPGA.If you ever want to run it standalone, simply reprogram the FPGA to use the dual port RAM to output video, and to provide a basic BIOS and a SD card interface or similar for bulk storage.

author: legacy
author_rank: Super Contributor
timestamp: December 16, 2015, 01:03:11 pm
content: Quote from: Bruce Abbott on December 15, 2015, 11:22:35 pmwhat do you think about realizing a PCB ?in case, I have already started this projectno time to complete

author: grumpydoc
author_rank: Super Contributor
timestamp: December 16, 2015, 01:11:12 pm
content: Quote from: Ian.M on December 16, 2015, 11:19:23 amA very valid point.I must admit I've been thinking much the same but it's 2015 - designing a Z80 system has to be forfunso whynottry to give it VGA graphics?QuoteZ80's, even at 20MHz are, indeed galacial when you start to think about it.However you wouldn't design any Z80 system with a pixel mapped graphical display which needed block moves for scrolling - at the very least you would design the graphics so that a start address for the frame buffer can be specified, scrolling then just becomes a question of updating the start address.I'd be inclined to use a separate graphics controller, there are quite a few to choose from intended to drive LCD displaysI'd also use one of the more modern Z80's - the eZ80 line looks interesting, certainly something with DMA to improve the speed of just shifting things around in RAM.

author: legacy
author_rank: Super Contributor
timestamp: December 16, 2015, 01:13:26 pm
content: Quote from: Ian.M on December 16, 2015, 11:19:23 amI have started a simple network filesystem, which can work over the serial portthis reduces the target complexity in several orders of magnitude!as far as for the debugger, I have developed a simple TAP (VHDL) && host code (ANSI/C)even if the TAP can be implemented to look similar to a gdb-stub, so it can be rewritten in C or assemblythe problem is: tooooooooooooooooooooooooooo much effort for these toys!I need a day made of 96 hours instead of 24, where- 7 gone asleep- 9 gone wasted when I have to work (avionics soooo boring sometimes)- 2 used for jogging || swimming && to piss out the dog !

author: Bruce Abbott
author_rank: Frequent Contributor
timestamp: December 16, 2015, 06:55:24 pm
content: Quote from: westfw on December 16, 2015, 07:04:55 amAtmel WinCUPL- 11MB on disk.

author: bson
author_rank: Unknown
timestamp: December 16, 2015, 07:36:41 pm
content: Quote from: grumpydoc on December 16, 2015, 01:11:12 pmThis is certainly true. A Z80 isn't viable for VGA graphics operations, except for very very limited use cases.One possible design to put e.g. 512k VRAM in its address space is to put aside a 4k region that can be mapped as separate read/write windows onto the VRAM. Map the 12-bit window using a pair of 8-bit registers, one for reads and one for writes, to form 20-bit VRAM read/write addresses and it can fit 1MB.If you only have 512k VRAM then put a 512k EEPROM in the upper half and use it to implement overlays by copying code into the remaining 60k of address space. Z80 era CP/M compilers will know how to emit overlays, although it imposes a tree code structure. At reset the EEPROM can be used in lieu of main memory for startup, which copies a boot image into main memory and unmaps the EEPROM.That's a ridiculous amount of work and logic though, only to create something that's pathetically slow yet neither useful or authentic...

author: Ian.M
author_rank: Super Contributor
timestamp: December 16, 2015, 08:00:39 pm
content: As I said: its *VERY* attractive to use something like a $5 Raspberry PI Zero, to provide graphics, bulk storage and even the keyboard interface. If you don't want to go the full FPGA route, the basics would just be a dual port RAM and an interrupt line in each direction for handshaking. Even with 'vanilla' non-programmable glue logic, that's easily achievable.

author: westfw
author_rank: Super Contributor
timestamp: December 16, 2015, 11:07:16 pm
content: QuoteYes, this is what happens when I think about designing some sort of "historical" system. "x is pain to do in logic. I know! I could use a modern microcontroller to do X! Wait - now that I have a modern microcontroller, why was I trying to design a YYY based system, again?" In addition to providing an easy solution for graphics/storage/keyboard, an RPi0 can probably emulate most legacy z80 systems in faster than real time...(So I have yet to get around to building a legacy system :-( )(There's also the "Wouldn't it be fun to enter a program on front panel switches, like in the old days? Sure it would! No, wait. I actually did that once. It was NOT fun... :-( )

author: Ian.M
author_rank: Super Contributor
timestamp: December 16, 2015, 11:28:24 pm
content: That is why building a retro computer should only be contemplated if you are interested in the hardware implementation. A Linux SBC is a cheap crutch to get your retro system working sooner and more easily than you would otherwise. If you make it modular with a backplane, you can move towards an entirely retro system step by step, though %DEITY% only knows where you are going to find a Shugart Technology ST-506 in good working order!

author: grumpydoc
author_rank: Super Contributor
timestamp: December 16, 2015, 11:33:30 pm
content: Quote from: Ian.M on December 16, 2015, 11:28:24 pmhttp://www.ebay.co.uk/itm/NEC-D5124-ST506-MFM-HARD-DRIVE-10MB-fd1c15-/400990411216?hash=item5d5ce419d0:m:mNRM6eNxFmS6hvkiqfmaWPgYou just knew, really, didn't you, that it would be ebay

author: Ian.M
author_rank: Super Contributor
timestamp: December 17, 2015, 12:45:31 am
content: Uh Oh! Unfortunately the NEC D5124 was first shipped in 1983. That's a bit of a downer if you are shooting for the heyday of S100 bus Z80 systems just before the launch of the IBM PC in 1981.However, on the up side, NEC still have a support page for it! O0https://support.necam.com/legacy/harddrives/d5124.cfm

author: C
author_rank: Super Contributor
timestamp: December 17, 2015, 01:13:00 am
content: Why not just put a SCSI-1 interface on it and use it for all IO.Can be very fast and yet you do not have to worry about loosing data.You have command / data separationTerminals, printers and more have been connected over SCSIHas been used as a small network between computers.Can be very simple in logic

author: miguelvp
author_rank: Super Contributor
timestamp: December 17, 2015, 07:16:02 am
content: Well, I did buy some of those chips bson mentioned, not for a Z80 and I do get they'll be a bit of a pain to get them working on my PSoC chip.But for the price they are pretty good, you can use the same address space to get 8 bits with two of them, one upper nibble the other one lower nibble. Put two and you got a double buffer, that is handy even if the memory is already double ported.Well, just took a glance at the datasheet before I bought them, still they might bite me to get 8 of those chips.

author: Bruce Abbott
author_rank: Frequent Contributor
timestamp: December 17, 2015, 07:25:20 am
content: Quote from: legacy on December 16, 2015, 01:03:11 pmV9958 has 1.78mm pin spacing so it will definitely need a PCB. My intention is to make a daughter board with DRAMs etc., and a connector with enough pins to interface to the CPU board. I am thinking stackable boards with a single row of 0.1 inch pitch pins on each side, or a double row connector on one end, or... so many choices!I have had enough of manually wiring boards (just spent several hours trying to track down a bug in my code, only to find that I had wired the UART reset signal to the wrong pin!). From now on I will design all my circuits with Eagle CAD and have the boards made by OSH Park. Turn-around time from OSH Park is 2-3 weeks, but I have so many other projects to work on that the wait isn't an issue.

author: legacy
author_rank: Super Contributor
timestamp: December 17, 2015, 10:30:17 pm
content: Quote from: Bruce Abbott on December 17, 2015, 07:25:20 amof course, even if adapters to 2.54 are available: I to not like them at all and I prefer a PCB with 4-6 DRAM installed!Quote from: Bruce Abbott on December 17, 2015, 07:25:20 amI'd like to conclude my two VDUs, the first is VHDL, the second is V9958. Just them!The target is a 68000 board I have already built, even if it needs a lot of improvements.Currently I am busy the the TAP, which is a mixage of VHDL + hardware staff + firmware stuff + C codeI hope to conclude a mile stone by the end of this yeas & probably I will not respect the deadlineQuote from: Bruce Abbott on December 17, 2015, 07:25:20 amgood!

author: westfw
author_rank: Super Contributor
timestamp: December 18, 2015, 09:31:09 am
content: Dual port (parallel/serial) memory chips, cheap:http://www.ebay.com/itm/8-TC524258BZ-80-DUAL-PORT-VIDEO-RAM-256Kx4-512x4-150-30ns-5V-ZIP-28-DRAM-VRAM-/271632014082?hash=item3f3e879b02I don't quite understand how they're supposed to work; it looks like the address pins are shared. (IIRC, the "serial" access loads up an address normally, and then gets consecutive addresses piped out the serial port at each (separate) clock for "a while." But wow, there are a lot of different cycle types in that datasheet! I don't think I ever quite figured out all the possibilities in between "software refresh" and "use a DRAM controller built by someone else. (I didn't have to!))

author: legacy
author_rank: Super Contributor
timestamp: December 18, 2015, 12:27:28 pm
content: @Bruce AbbottI have created an Eagle cad library, the V9958 is burned in!I just guess about the CRT signals as this chip need something able to follow H & V synchronism, which are not VGA compliantand it sounds like jam as I do not have such equipment.

author: legacy
author_rank: Super Contributor
timestamp: December 18, 2015, 12:31:37 pm
content: Quote from: westfw on December 18, 2015, 09:31:09 amummm, fpga + dram (~ papilo/pro ?) sounds like keep getting better in VDU project( mine is coming for xmas )

author: Bruce Abbott
author_rank: Frequent Contributor
timestamp: December 18, 2015, 06:41:29 pm
content: Quote from: legacy on December 18, 2015, 12:27:28 pmYes, it is a problem with most of these retro video chips. You need a scan doubler or upscaler. My solution is the Gonbes GBS-8200 upscaler, which sells for less than US$20 on eBay. Like most upscalers it has artifacting issues with non-interlaced video. I made a little circuit for it that bypasses the normal controls and loads configuration data directly into the upscaler chip.

author: legacy
author_rank: Super Contributor
timestamp: December 18, 2015, 10:13:19 pm
content: excellent!and you have remembered me when I openedthistopic a while ago

author: obiwanjacobi
author_rank: Super Contributor
timestamp: December 22, 2015, 07:11:23 pm
content: This excerptmade me think, you do have access to the memory half of the time if you don't use DRAM...Now what could I do with that...

author: Ian.M
author_rank: Super Contributor
timestamp: December 22, 2015, 08:30:26 pm
content: IIRC You only get one refresh per M1 instruction fetch cycle. That means that if you need the maximum memory bandwidth consistently, the Z80 must only execute 4 T state instructions for the length of the transfer.

author: grumpydoc
author_rank: Super Contributor
timestamp: December 22, 2015, 10:25:59 pm
content: Quote from: Ian.M on December 22, 2015, 08:30:26 pmYou are correct but the scheme presented does not requite that only 4 t-state instructions are executed.The video controller used uses a double 80 character row buffer, the data in each row is used repeatedly to drive the character generator - so the data only needs to be refreshed everynscanlines wherenis the height of the character cell.Assuming an 8x8 cell this means 80 bytes every 512us - the longest Z80 instruction (on a quick recheck) is 23 t-states (RES (lY+d)*) so 6us on a 4MHz Z80 - 6x80 is 480us so just enough time** even in the worst case.* But IIRC you get two M1 cycles with the index reg operations.** However *some* time will be needed to set up the registers for the transferIt's a bit of a hack, means you can't use mode 2 interrupts because you need to use the I register to form A8-A15during refresh cycles and each character row will have to start on a 128 byte boundary because the R counter is only 7 bits and odd things will happen if it overflows during the transfer.

author: stmdude
author_rank: Frequent Contributor
timestamp: December 23, 2015, 11:08:30 pm
content: I've skimmed the pages of this topic, but I couldn't see _what type_ of graphics you're planning to display, as the "optimal" solutions vary quite a bit.If you want to be able to do completely bitmapped graphics (think home-computer), you're sort of on the right way with mapping video-memory into the systems address space.However, if you're looking to display text or old-school 2D game graphics, you're just getting yourself into unneccessary trouble by doing this. By old-school 2D game graphics, I'm talking about stuff you saw on the NES or Genesis/MegaDrive.The way they approached it was to have a very early version of a discrete graphics card, with its own memory, that you uploaded data to (through MMIO or regular IO), and then told it to basically "put graphics A at position 0,3" by use of a tile-map.The concept of tiles is explained in the following video:Andy Brown did something similar as well, using an FPGA to be the discreete graphics card, and an STM32 as the main CPU. He has a very good writeup here:http://andybrown.me.uk/2014/06/01/ase/Oh, and the tile-map concept works very well for (monospaced) text as well.

author: rrinker
author_rank: Super Contributor
timestamp: December 24, 2015, 04:51:48 am
content: C got here first with the TRS-80 stuff (I had a 4p). That ROM file made for some interesting hacks - also the 4p could be booted over the serial port. I don't think the video memory was bank switched out, but I just tossed my set of technical reference manuals. There was also a "hi res" graphics board, but it wasn't full VGA, I think it was 640x240. That had its own video memory and display chip. That's the one option I never had, instead I had the Dotplot program which allowed you to make hi res graphs of math functions by individually addressing the print solenoids in a dot matrix printer. Quite clever.Having that full 64k available made it possible to run all sorts of operating systems. Being able to run CP/M and the version I had's capability to read and write any disk format the drive was physically capable of helped save a lot of time in my intro Comp Sci class in college, which involved 8080 assembly, it it proved the conduit to get my first terminal emulator onto my first MS-DOS machine.Very interested to see how this turns out. Another interesting bit (but I do not have the link on my iPad) is a fellow who built a Z80 system in an Altoids tin.--Randy

author: miguelvp
author_rank: Super Contributor
timestamp: December 24, 2015, 06:49:35 am
content: Actually with the project I'm working on and posting in here:https://www.eevblog.com/forum/projects/no-bitbanging-necessary-or-how-to-drive-a-vga-monitor-on-a-psoc-5lp-programmabl/The prototyping board has plenty of GPIOs left to read a dual ported frame buffer to act as a display card. Or even use some serial protocol including USB.I'm expanding from the CGA proof of concept I did a while back:https://www.eevblog.com/forum/projects/make-use-of-an-old-cga-monitor/msg697201/#msg697201That proof of concept can drive an old CGA monitor with just 7 pins since they are TTL level so no external DAC required:But before I moved to CGA I was working with a VGA monitor:The sprites came from finding an image on the internet, organizing it and writing a program to produce the file format I needed to fill in the PSoC 2KB EEPROM.So on the ongoing project I'm just planning to do a CGA palette but if the frame buffer is enough it can do 3 bits per color (512 total) using that cheap VGA module.Or even drive this 8 bit per color DAC, but unfortunately the PSoC module can only reach 80MHz with a very precise external OXCO, but with a good XTAL it probably can achieve video modes that require 75MH pixel clock, the good color DAC can reacy 330MHz but not the Cypress board.https://www.eevblog.com/forum/microcontrollers/ov5640-hack/msg446190/#msg446190This is the board:But it used 31 pins plus ground, not sure how many were absolutely necessaryFPGA connectivity shown here, never tries that module on the prototyping board (yet)Edit: BTW my dual port video ram arrived, all 8 64Kx4bits or 512KB worth.And yeah, I edited this just to show off the book behind the chipsWhat can I say I started with the ZX81 but the Spectrum is my turning point. Wrote an assembler and emulator for PC, even an assembly program to read the tapes on the old IBMs that had Cassette Din ports on the back.Oh and the z80 emulator could debug too.

author: obiwanjacobi
author_rank: Super Contributor
timestamp: December 24, 2015, 11:52:33 am
content: Hehehe, I had that book tooFor now I have parked the video memory problem in my design. The reason I brought it up was because I thought that perhaps there were design choices for banked memory and video memory that interfered. And there are and they do but in the spirit of "small steps, Elly" (Contact) I decided to get a basic Z80 system running first. Progress so far is that I have a running Z80 NOP-test circuit and have started to put down the schematic and thinking about the system in a little more detail.The discussions here did make me more aware of potential pitfalls and alternate solutions. During researching the video options I ran into theseries. A very small but very powerful (so it seems) graphics generator chip that may be an option.However, I still am not entirely sure on how to partition the memory banks (4k/8k/16k/32k??) and how to let the software deal with that. Also in light of a future file system, how are files loaded that are bigger than the memory page? How do you manage that etc. That is still a big question for me.

author: Ian.M
author_rank: Super Contributor
timestamp: December 24, 2015, 12:31:45 pm
content: Unless one of your primary interests is recreating legacy graphics systems, I believe most of the non-hosted graphics options to be a very large amount of work for not that much gain. The FTDI EVE 2 is just offloading the graphics to a custom processor - conceptually not much different to using a host computer or a nintelligent serial terminal. However its QSPI interface isn't well suited to the Z80 bus without quite a bit of glue logic.One of the suggestions I made - to use a fast '486 era cache RAM for page translation would be capable of multiple page translation tables that could be switched with a single OUT instruction. That combined with a 4K page size and separate read and write mapping gives you the most flexibility. How to deal with it in software - well if you are running the system 'raw' with no OS, you simply page in program or data memory as required. Done right, execution can continue from the instruction after the paging OUT in the new page, or you can have a paging routine you call (probably via a RST) that reads the page, and address to call from inline data bytes after the RST, does the paging, calls the routine in the new page and on return, reverts to the previous page, fixes up the stack to skip the inline data and returns to the main program. If you are going to run CP/M+ or MP/M, then you need to write a BIOS for it to provide compatible paging routines.Perhaps you could expand on the subject of your concerns regarding the filesystem?I don't see any great issues with writing a routine to read N sectors from bulk storage and transfer them to contiguous locations in physical memory.

author: legacy
author_rank: Super Contributor
timestamp: December 24, 2015, 02:50:56 pm
content: you can look @ gameduino2, i comes with an LCD and it uses a custom GPU, with a serial interface!

author: obiwanjacobi
author_rank: Super Contributor
timestamp: December 25, 2015, 06:04:41 am
content: I think Gameduino also uses an FTDI EVE chip...I get how to switch the memory page, both in hardware and software. I get how to read a file - that is not the issue. What I don't get is how big to make the pages and what the pro's and con's are for the size and how to manage a program that is bigger than the memory page size. I cannot see a way to make that work elegantly without imposing a whole lot of restrictions on the program itself. Or what all of those restriction are in the first place.I think this also has to do with the fact that it is very hard (almost impossible) to write relocatable code for the Z80 unless its a very small program..? So there have to be fixed start addresses for the programs (which is fine) but I would like them to be page agnostic.[Progress - a bit off topic]The tools (that are any good) I have found so far ar theZ88 Development Kit (z88dk)which provides an Z80 Assembler, a C compiler and a Linker and supports a lot of old Z80 machines (I don't need). But it is pretty easy to re-target. Also found theSmall Devices C Compiler (SDCC)which can also be dropped into z88dk.I decided to use KiCad instead of Eagle because I could not get Eagle to work with a project that is not in its own project folder (which is a totally flawed concept to begin with). But that means I am on a bit of a learning curve for KiCad. Luckily I have founda nice channel with lots of tutorial video's.

author: Ian.M
author_rank: Super Contributor
timestamp: December 25, 2015, 09:44:44 am
content: The critical limitation on program size is 64K, the Z80 address space as paging aware Z80 compilers either don't exist or are vanishingly rare.Consider a program that is explicitly coded to be paging aware, and has data structures designed to be accessed via a paging window. Consider also that one would want a standardised method of accessing system routines, and that due to the Z80 having fixed low memory interrupt and RST vectors, it vastly favours putting system support code in the lowest page.The resulting memory map will look like this:0xFFFF ----------------------paged user data----------------------User program, variables and stack----------------------System entry points, ISRs etc.0x0000 ----------------------Its fairly obvious that the smaller the page size the less it squeezes the user program area. It would be possible to extend downwards into the lowest page, but then each program would need its own copy of the system and ISR entry points, which is rather undesirable. With 16K pages, you'd have up to 32K paging aware programs. 4K pages gets you up to 56K for programs.If the intricacies and limitations of writing code for a paged Z80 system don't entirely hold your interest, there is very little point in building one. It would be much simpler to use an i8088 processor with native access for a 1MB address space and compiler support for it as well. However I personally find legacy DOS era PCs rather boring but YMMV. It may well be that a simple 32K RAM 32K ROM and memory mapped I/O Z80 board is all that you really want and need.

author: grumpydoc
author_rank: Super Contributor
timestamp: December 25, 2015, 10:53:23 am
content: QuoteIt is not harder to writerelocatablecode for the Z80 than for other platforms - you just need a separate list of the instructions to modify when a code segment is loaded.I suspect, however, that you mean Position Independent Code (PIC) whichisfairly difficult to do on a Z80 because the target range for relative jumps and index register operations is only a (signed) 8-bit offset.The OP asked about page sizes - I would suggest that 4k is a good balance and can be achieved by mapping the top 4 bits of the address bus. Smaller and it will be too much work to bring stuff into the 64k address space, larger and you loose flexibility.I would definitely consider writing a CP/M 3 BIOS for your system - you will then gain access to a good volume of existing software (including compilers and assemblers) and the operating system supports a simple banking scheme for extending the memory space.If you are massively keen to just implement a system and do everything from the ground up for the experience of doing so but want >64k RAM andrelativelyhigh resolution graphics I would suggest that a Z80 system is not a good place to start - the CPU poses too many limitations which can only really be overcome with hacks and kludges.A system based on the Motorola 68k would make far more sense, and you get a lot more performance at a given clock speed.

author: obiwanjacobi
author_rank: Super Contributor
timestamp: December 25, 2015, 11:38:46 am
content: Quote from: Ian.M on December 25, 2015, 09:44:44 amWhy is it not 48k with 16k pages (and 60k with 4k pages) - assuming one bios/system/jump page (which fits into 4k for the last example)?Ok, So what I need to figure out is how to manage all the memory-page bookkeeping for the program. I would not want to allow programs to switch the memory pages by themselves and use one of the program memory pages as jump page - I think. Indeed I see a RST bios service routine that takes care of that for the program.Quote from: grumpydoc on December 25, 2015, 10:53:23 amYes, that is what I meant, thanx for clearing that up. In fact I think the z88dk has support for relocatable code at a fairly hefty overhead of something like 3k!Quote from: grumpydoc on December 25, 2015, 10:53:23 amYes, that is something I am considering to start with. But I have not researched the details of that yet. It would actually be interesting to see how CP/M does the memory bank switching (in software).Also, I have decided to start with a very basic system first - without video for now. So I don't know if and how to fit CP/M onto that yet - but my guess is that I could simply route video-out to serial-out in my custom bios (guesses may be wrong though).

author: grumpydoc
author_rank: Super Contributor
timestamp: December 25, 2015, 12:40:59 pm
content: Quote from: obiwanjacobi on December 25, 2015, 11:38:46 amAll the documentation is online, the bank switching is pretty easy but it's a while since I read through the docs. I haven't actually implemented a CP/M 3 BIOS although I did write a CP/M 2.2 BIOS and it wasn't exactly hard.QuoteCP/M just needs single character input/output routines to be implemented - this can easily be via a UART

author: obiwanjacobi
author_rank: Super Contributor
timestamp: December 25, 2015, 12:52:01 pm
content: I always have trouble with "here are all the source files" documentation

author: grumpydoc
author_rank: Super Contributor
timestamp: December 25, 2015, 02:28:05 pm
content: Quote from: obiwanjacobi on December 25, 2015, 12:52:01 pmI would suggest that you look at the information on the web regarding CP/M, your comment suggests that you haven't.The BIOS is well defined and documented. You were planning on writing your own - it is hardly a more difficult task to write to an existing spec.There is detailed documentation for what you need to implement herehttp://www.cpm.z80.de/manuals/cpm3-sys.pdfVarious binaries and source code can be downloaded herehttp://www.cpm.z80.de/

author: C
author_rank: Super Contributor
timestamp: December 25, 2015, 03:03:18 pm
content: A USART as an interface to the world is simple but immediately adds a bunch of problems.First is the speed problem. What speed, to slow and Z80 waits to output, to fast and you have over run on input. To fix this the best choice is a hardware handshake using the extra hardware lines of USART.Now you have an 8-bit data stream where all 8-bits are used and want to add control information like this character is red, flashing or is current input location on screen. You now have to funnel more data through the same 8-bit data stream. Simple just went out the window and added a lot of software overhead.CP/M uses a printer port, You now need a second USART or need to funnel even more data streams through that one 8-bit port.On top of this CP/M wants some mass storage. Many more 8-bit streams that are based on blocks of 8-bit data. And you have even more control data to select what.To keep it simple, you need an interface that can separate what is control information and what is 8-bit data and does hardware handshake on a byte level to prevent input overrun while allowing max speed for output.You can then use the control information to specify what the 8-bit stream of data is. To save software time, it would be nice to not have to pack two or more blocks control data into a single byte. Would also be nice to not have fixed size control or data blocks.It's not hard to find this has been done in the past and is still done in the present.If you are looking at this page then you are looking at an example. The problem is this example caters to human reading adding a lot of overhead for a processor.In the past for serial links was Synchronous block framing links using HDLC & SDLC. These used hardware bit stuffing to allow known start & end of a block. By knowing the start of a block you can have a simple to decode control vs data.For very simple parallel interface you have the SCSI interface. This can be very simple for a Z80. If you use two output ports, you can use A0 to specify the control vs data on output. Hardware handshake is a simple FF that is set when these ports are written to.For input you could have two ports, One to read status and if the byte is control or data and a data input port that resets the FF on port read.By using a control block of data, both ends of the link become simpler for software and allow the one link to be what would take many hardware interfaces.To add to what grumpydoc suggests I would add looking at the IMS Z80 TurboDOS 14 Implementers Guide.pdfhttp://maben.homeip.net/static/S100/IMS/software/IMS%20Z80%20TurboDOS%2014%20Implementers%20Guide.pdfThe advantage of TuboDos is that a single Z80 can be whole system like CP/M3 but have option of having one or more systems to assist the Z80.Looking at the character based I/O shows that a simple software standard can be used to work with many I/O devices.C

author: legacy
author_rank: Super Contributor
timestamp: December 25, 2015, 03:05:03 pm
content: how to attach a narrow (8bit)/Single Ended SCSI interface to an MPU ?

author: obiwanjacobi
author_rank: Super Contributor
timestamp: December 25, 2015, 03:36:59 pm
content: I will look into CP/M after I have the basic hardware up and running. I did glance at the CP/M documentation but could not find my way in there very easily. Thanks for pointing out the documents gentlemen, that will certainly help.I will start with a UART for basic IO but that will not mean I will stop there. Already have been peeping into building an IDE interface, which doesn't look so difficult. SCSI may be easier - I don't know- but I do know I have no drives for that. I think I still have a couple of old IDE drives that perhaps I could use.Anyway, first things first.

author: Ian.M
author_rank: Super Contributor
timestamp: December 25, 2015, 03:56:15 pm
content: CompactFlash cards (not CF+) have an interface that's electrically compatible with PATA IDE. If I was building a retro system, I would rather trust solid state storage than old spinning rust!

author: station240
author_rank: Unknown
timestamp: December 25, 2015, 04:32:25 pm
content: Quote from: Ian.M on December 25, 2015, 03:56:15 pmYes +1 to thisEasy to get CF to IDE adapters off ebay for a few dollars. Even cheaper than just buying the CF socket on it's own.You could also later consider adding an IDE CD/DVD rom drive to the system, so you can have an entire Filesystem image on a CD. the ISO 9660 should be easy enough to understand.

author: C
author_rank: Super Contributor
timestamp: December 25, 2015, 05:18:32 pm
content: In place of trying to adapt something newer to the old Z80 and having a mess. Would be much easer and faster to just use a SCSI like interface to connect to something new that you can control.that one interface connected to something like a raspberry pi would let you have all the I/O you would want.Going a step further SCSI is multi-host, so you could have a second Z80 & raspberry pi connected. Up to 8 hosts on SCSI-1In the keep it simple, look at how much I/O you can get by connecting to something in the line of STM32. The Z80 could then access many serial ports with a simple program on STM32. Do I need to say that one or more serial ports could be over USB to a PC.An SD card could be the Z80's hard drive.Would be simple to have the Z80 working with many drives that on other computer is just a file. This keep the operating system on Z80 working.One simple interface on Z80 that can have simple Z80 software driver and open up the world for I/O.By having control of both sides of the link, you have control to make it work.The hardware does not have to match SCSI just need the same ideas in place.. Where SCSI-1 has a bidirectional open collector buss you could adapt the idea to what would be simple at both ends. The advantage of open collector is that many drivers can try to talk and not have a logic fight.Need to keep in mind that what works with current hardware may not work with a slow Z80. You can break software and hardware by being to slow or too fast.Many I/O devices have a min speed. For floppy drives, you work at this speed or have to add something that gives you a window that will work.Think of what you may have seen in past. That scanner that stopped and backed up a bit if you did not read the data at speed. How many CD's have been pitched by not meeting the min write speed.Think of how much software will be needed to just control some of the new devices. If the Z80 is talking with something new that can talk to these devices the software needed just became a lot easer.Get from the old to something new that is better able to handle the problems while at same time keeping the hardware simple.

author: Bruce Abbott
author_rank: Frequent Contributor
timestamp: December 25, 2015, 06:36:54 pm
content: Quote from: obiwanjacobi on December 25, 2015, 03:36:59 pmCP/M is a horrible operating system. I wouldn't consider it unless there was some specific CP/M application that I wanted to run.CP/M creates (almost) 64k of RAM address space by loading essential BIOS functions into low and high RAM and then switching the boot ROM out. Everything else - including most DOS commands - is loaded from disk into the TPA (Transient Program Area) starting at location $0100. This creates a lot of disk activity and makes it difficult to have more than one program in memory at once. The BIOS itself can switch in ROMs or extra RAM as required, but this is normally hidden from user programs.QuoteGood idea. Even if you upgrade the display and keyboard hardware it will still be useful for debugging etc.QuoteIDE is very easy if you don't need DOS compatibility. You can use a simple 8 bit interface, which ignores every second byte and so wastes half the drive capacity - but who cares when you still have Gigabytes available?QuoteIDE is basically SCSI but with a more friendly bus interface.QuoteThe way I did it was to create a set of small subroutines or macros that replaced certain CPU instructions such as LD A,(HL) and LDIR. The only problem with this approach is that the code may be much slower, therefore having an efficient page switching system is very important. It should be able to:-1. Switch pages in and out with as few instructions as possible. Paging hardware should be arranged so that a single OUT(port) instruction will select the desired page read/write combination. Page select bits can be lined up with the upper address bits, so the high 8 bit register of a 16 bit pair can be sent directly to the port. These bits could map expanded memory into a 'window' while keeping the OS ROM etc. active. Another paging register could put the mapper into different modes, or select 'special' page combinations that might be useful.2. Allow reading from one page combination and writing another without any switching. This can effectively double the base memory addressing range with almost no overhead.3. Keep track of which pages are currently selected so it doesn't have to switch them unnecessarily, again using as few instructions as possible. The alternate register set can be used to do this.QuoteAs Ian.M said, the major limitation is the Z80's 64k addressing limit. Any program that wants to address a greater range needs extra code to handle the higher address bits. However in most applications 64k is enough, the problem being how to maximize usable RAM inside that 64k. The OS ROM, system variables, and memory mapped peripherals (eg. video RAM) all eat into that space. The paging system needs to switch all of these out of the way when desired, but still have them available when necessary.

author: C
author_rank: Super Contributor
timestamp: December 25, 2015, 07:01:33 pm
content: Quote from: legacy on December 25, 2015, 03:05:03 pmLook at the interface to SCSI that is in the LOBO MAX-80. Not a lot of chips needed.If you look back at SCSI-1, it is a simple buss.Does not take a lot of software to get working at a low level.You are building up a block of data to tell the device on other end what to do, the control data block.Each chunk sent over the buss has a control block and a optional data block. The hardware keeps the two distinct by having a 9-th signal. There is no need to mess with 8-bit data to keep control data separate from data data. By using A0 to generate this 9-th signal, output can be very fast. If you think of the quick tests a Z80 can do to 8-bit data, you can make the input simple. Read a status byte, One instruction gives you 0, Negative or positive. So you can easily test if the high bit is 1,0 or all are 0. A shift instruction and test instruction gets you another bit.By arranging the bus signals in the status port, you can make it easy and fast.It can actually take more software to work with that nice fancy SCSI controller. The fancy SCSI controller then puts a lot of limits on what can be done for some gains.The same is true for working with the IEE488 bus direct or with a controller.The big problem comes with all the software layers that have been stacked on top of the simple. If you do not have control of both ends then you have to match up to the standard of that device. Do you really need all the layers to function at the Z80 or could the middle man computer do these?If you have control of both ends then you can create new command blocks to do a function. In place of creating the fancy escape sequences for terminal control that only work with one specific terminal, you could have a simple command block that has the data needed. The middle man computer could then do this work.You can have a network of 8 computers on SCSI-1 based on that hardware.The important things that SCSI does is1. hardware separation of two types of data, With simple hardware this is almost free.2. This hardware separation lets you know starting point of each by this change.3. Hardware handshake a byte level.4. The buss lets more then one host exist.If you look back A Z80 most times did not directly control a hard drive. It used the SCSI buss to talk to a (z80)controller the then worked the hard drive.Hard to find on web these days, there was a lot of different types of equipment connected to buses like SCSI, not just storage like hard drives.

author: C
author_rank: Super Contributor
timestamp: December 25, 2015, 08:20:35 pm
content: Bruce AbbottOlder versions of CP/M were trying to do the best you can on the limited hardware of the time.You need to think of what the swap is doing. It's a trade of make the operating system larger all the time so that user programs had to be smaller or swap out parts of operating system so that user programs have more space.Still done to this day in operating systems.The reloads from disk where cured on many systems that had the hardware to do so. A ram disk does wonders here while keeping ease to change.If you have the RAM then CP/M3 can keep this in memory.Would guess that you never saw a large TurboDos system running. Some of the hardware for these were built to be cheap. It did not take much of a hardware change to get very fast. You just have to plan ahead when building the hardware. Each user had at lease a Z80. The better systems had a lot of ram connected to each Z80. Put a bunch of Z80's in a box, and connect the boxes. Easy to expand to a large number of anything in system.One thing to think about is the need of large memory for data. In the past when you needed more memory then you would have you used a disk drive. If you are trying to use the old Z80 programs the easy thing to do is just use a ram disk or a regular disk drive that has system cache buffer. While the program thinks it's reading a disk, what is actually happening is a memory swap.Some programs of the time did their own overlays using a disk.

author: grumpydoc
author_rank: Super Contributor
timestamp: December 25, 2015, 08:28:39 pm
content: Quote from: Bruce Abbott on December 25, 2015, 06:36:54 pmWell, umm yes, but.....If the intent is to build a Z80 based system then what are the options?TurboDOS has been mentioned which looks interesting but I'm not sure how much work getting a system running would be.CP/M3 is well documented and there are fairly extensive archives of CP/M software - especially things like assemblers, compilers and emulators - which will all make the task of getting a system bootstrapped easier.After that? Well, roll your own but to do anything useful you need to do the OS and tools and applications yourself which seems like a lot of work.Also, crud compared to what? 8-bit operating systems are all a bit crufty if you ask me.While I can see the point of building a Z80 system from scratch in 2015 - in fact I'm pondering it myself just because I have a lot of Z80 bits in the parts drawer - I can't really see the point of writing a Z80 based operating system.SCSI has been mentioned - I'm not sure that this is such a good idea either. SCSI-1 was supposed to run at 5MB/s which no Z80 is going to be able to do if you are bit banging an interface. It was an asynchronous interface so might run slower (never tried) but if you are doing programmed I/O on a Z80 with handshake then expect not much more than 20kB/s but the real reason is that there isn't exactly a lot of suitable hardware still kicking around.Building a simple 8-bit IDE interface makes much more sense so that would get my vote. It's pretty easy, there are lots of notes and schematics on the web and you can hook up to a CF card. In fact it might even be possible to use an IDE->SATA interface and talk to a completely modern drive. Crazy but it might just work; a CF card maks a lot more sense though.Serial I/O - use the Z80 SIO or a 16550, Centronics - use a Z80 PIOUSB might also be doable using something like the FT245R which opens up quite a few possibilities.

author: Ian.M
author_rank: Super Contributor
timestamp: December 25, 2015, 09:46:45 pm
content: That's another reason to use CompactFlash - it has an 8 bit mode.Thert is no point whatsoever in implementing SCSI 1 as compatible hardware is now vanishingly rare. OTOH a GPIB interface would be truly worthy if you have even a small collectrion of test equipment with it.I still think the best host interface would be a reasonably large dual port RAM to a linux SBC, with a FPGA to manage full Z80 bus access so you don't have to burn any ROMs to bootstrap the Z80 side and to allow you to implement a full transparent monitor/debugger. That would vastly ease cross-development.

author: C
author_rank: Super Contributor
timestamp: December 26, 2015, 12:39:47 am
content: grumpydoc:Think your missing the keep it simple while at the same time very expandable.QuoteThe next step pass SCSI-1 is SCSI-2 which has a max of 10MB/s while still the same, just better bus drivers. Both will slow down with out loss of data. If you want to push to a faster speed then the Z80 can do then you need to use DMA.With proper designed hardware the Z80 can go a lot faster then 20kbs.My old Lobo at 5.3 meg clock can use 8" DD floppys with out DMA. If my math is correct that is 62.5k bytes a second.The SCSI interface is faster due to not having the critical time requirement in software.A good SCSI interface you are not bit banging.If you control everything connected to the bus, nothing prevents you from defining different control blocks on the bus.Just so you know, most CP/M software will still function when using TurboDos as a operating system. TurboDos does add some system functions that programs can use along side of the CP/M system functions. Because this system was built with the idea that each user has a Z80 and all I/O can be local or via a network is the big advantage. Most used the S-100 bus to link the local Z80 users to other processors, but this can be over many types of buses. You are just sending chunks of data over a bus.One thing that TurboDos adds due to this remote I/O is many different I/O streams. These can be remapped. So while CP/M is limited on I/O ports like the console & Printer, TurboDos allows easy access to a large number.Now why do you need to recreate the operating system? One Z80 is like your PC while the others look like a mapped network drive, printer, com port. It is a powerful system. By using CP/M or TurboDos drive interface you could have a system drive that exists as a file on something new.To expand this you could add the capability of block based I/O. This would allow reading and writing files not stored on a CP/M format block device.All you are really doing is putting TurboDos network data on SCSI hardware bus.By using one byte in front of this data you can switch formats of data.1 = TurboDos network data2 = multi-disk logical block data3 = Multi-stream Byte I/O4 = debug byte I/OWant something new, simple software change on both ends.So just to be very clearUse the SCSI-1 hardware layer to connect from one or more Z80s to NEW Processor and connect more NEW Hardware to this NEW Processor if needed.If the NEW Processor is a Raspberry Pi then the SCSI hardware connection would let you tab everything the Raspberry Pi has just by adding some software.

author: Bruce Abbott
author_rank: Frequent Contributor
timestamp: December 26, 2015, 02:16:22 am
content: Quote from: grumpydoc on December 25, 2015, 08:28:39 pmIt doesn't make sense to develop software on the target machine if you don't have to. A modern PC can cross-compile much better and faster than a typical CP/M Z80 system could, and you can download code into the target machine in a few seconds. Even burning code into an EEPROM is quicker.QuoteYou don't have to write an OS from scratch - just grab an existing one and modify it. Developing low level drivers is the hardest part whether you use CP/M or some other OS. The problem with CP/M is you are forced to do everything the wayitwants.QuoteI have an Amstrad CPC6128. For several years this was my main computer, which I used for cross development on other Z80 based machines. It came with CP/M 3 as an option. The only thing I ever used CP/M for was formatting and copying discs (which was painful if you only had one disc drive, because you had to swap discs several times). Other disc utilities that ran under AMSDOS were more powerful and user friendly, plus you could quickly hack together your own stuff in BASIC. Many ROM-based utilities were produced that provided instant access without having to boot a system disc and then load the application fromanotherdisc.My idea of a good OS is one that boots instantly and is fully functional 'out of the box'. Modern systems have gone backwards in this regard. My PC gets left on for hours because turning it off and on again takes too long. I don't turn my phone off because it takes forever to boot, and I keep 3G turned off because it tries to download updates all the time.QuoteThe whole concept of a Z80-based system is pretty pointless today - except for fun. I agree that writing writing a whole OS from scratch isn't most people's idea of fun. Luckily there is a fair bit of code out there that can be used as a framework.My goal is to build a Z80-based 'home computer' style system (like Amstrad, Spectrum, Sega etc.) which does things that weren't practical 30 years ago because it was too expensive and/or time consuming. I don't want to just throw in modern hardware that does all the grunt work, leaving the Z80 as a hood ornament. Idowant the Z80 to be in control and working as efficiently as possible, because Ilovewriting optimized Z80 code!

author: Bruce Abbott
author_rank: Frequent Contributor
timestamp: December 26, 2015, 02:36:01 am
content: Quote from: grumpydoc on December 25, 2015, 08:28:39 pmMany peripherals that have been designed to work with modern MCU boards (Arduino etc.) can be interfaced to the Z80, and don't require a lot of CPU power to operate. I am using a CH376 USB controller on my Aquarius, getting 110k Bytes/sec read speed over the 8 bit parallel interface.

author: obiwanjacobi
author_rank: Super Contributor
timestamp: December 26, 2015, 06:34:58 am
content: We're going pretty much off topic here but I will describe what my thoughts are at this time for the system, in order to direct and scope the discussion a bit.The idea is to build a modular system on a central bus. I want to be able to add stuff later. I have a Z80 CPU and for now 4x64k RAM - I will start with using only one of those. I have no ROM. Instead I am planning to use an MCU to provide a UART connection to a PC that can download programs directly into RAM. The MCU I am planning to use initially is anAtmel atmega128. It has a ton of IO and an external address / data bus, which means it can act as a smart DMA. The MCU will also provide the initial set of IO peripherals (SPI, UART, I2C, Timers/Counters etc). All the glue logic that is required for memory bank switching, MCU/DMA access, interrupt logic, Debug support etc will be in a CPLD - the Altera MaxII - for now. This is a non-volatile device with around 100 IO pins. It will generate the clock (50MHz?) and divide that down dynamically for the CPU (and MCU?) - meaning I can slow the system down for debugging etc as it runs (I hope that works). Having a programmable logic device gives me all the opportunity to experiment and evolve. Provided that the basic connections are correctly (thinking of having a PCB made).That is it, that is all that I have for now. I am currently working out the way the MCU will be interacting with the system, most importantly: how new programs are loaded into RAM. The CPLD is a black box for now. I describe what I need it to do but will flesh out the VHDL for that later - have to learn that too.I hope this gives you guys some idea where I am heading with this project. The goal is not to make period-correct hardware, or not to reinvent the wheel etc. This is a journey full of learning new things and I love to think about stuff like this - that is the goal. Reinventing the wheel gives you great insight in how that works and why - and it will beyourwheel. That being said, I also do like to have a project that will eventually work and that is why I try to work in little/small increments. So discussing SCSI or IDE at this point (for me) is pointless other that seeing if I have the correct signals on my bus to be able to extend that later.But I do appreciate this discussion very much. It has made me see (some) things in a different way. Thank you all for that.

author: miguelvp
author_rank: Super Contributor
timestamp: December 26, 2015, 01:35:57 pm
content: I do see one problem using the MAXII, it can provide 3.3V logic while the Z80 and Memory are probably at TTL levels of 5.0V.On the 4x64k RAM you can use two of those daisy chained and sharing the same memory addresses with one of the chips offering the high nibble (D7-D4) and the other doing the lower nibble (D3-D0) that way you have the full 8x64K.Using a single chip for the full 8 bit data bus (D7-D0) will mean you have to have them electrically wired together having D7-D4 sharing the same bus as D3-D0. That can of course be done because its all in the timing. And that provides the benefit of having a full 8x32K, leaving your the upper 8x32K address space to be populated at a later time with multiple banks selected via a demultiplexer controlling the chip select of those higher memory banks.Edit: Actually it will be more complicated to share the 4 bit bus for both higher and lower nibble, you'll need the CPLD to decode that so that the Z80 sees all 8 bits at once. So the CPLD could act as an ALU and manage all the Address and Data lines from the Z80.Edit: just to note that as I recall, I/O share D7-D0 so if for example you use a port to select the upper memory bank, you have to make sure that is not enabled on regular memory read writes, so it can get a bit tricky but not impossible.CS (chip select) pin usually is negative logic. So you have to make sure only one subsystem sharing the data bus has the CS low and that the timings are correct for accessing or writing the data. All that could be done within the CPLD.For programming the device, you can halt the Z80 or hold it on reset (not sure on the pin details without looking it up) load the memory while the Z80 is not active with the program. And restart the Z80 via it's pins.The Z80 will start or you can provide the reset irq and fetch the boot address. Both boot paths should take you to the same start path, well not necessarily but just to keep it simple.I do think the PSoC 5LP prototype kit will serve you for your CPLD and MCU needs including the UART connectivity to the PC in one module. Plus give you expansion for other systems including the VGA controller.And it can do 5V and support more than one voltage rail acting also as a level shifter if needed. Although I don't know of the top of my head if those other voltage levels are exposed in the prototyping kit, otherwise you might need to spin your own DIP compatible board.

author: obiwanjacobi
author_rank: Super Contributor
timestamp: December 26, 2015, 03:02:23 pm
content: Sorry, I have 4 chips of 64kx8-bits (UM61512AK). That is why I said I would start out using only one of them...Fromwhat I can readthe Max II is pretty easy with its 5V tolerance...The Z80 will tri-state its bus on reset and busreq. I was planning on using busreq as a generic way gaining access. I also want to have somedebug featuresthat may want to peek and poke into the memory where I could reuse that.Yes, that PSoC is beginning sound good - although what I have now is very cheap. Also have no experience with PSoC. The idea of the FPGA was born out of having a video output that it would generate. Perhaps time to rethink some of this...(BTW: Have my first 'hello world' CPLD/VHDL program running, an 8-bit counter.)

author: grumpydoc
author_rank: Super Contributor
timestamp: December 26, 2015, 03:19:45 pm
content: Quote from: C on December 26, 2015, 12:39:47 amI'm trying not toQuoteOK, yes I agree you probably don't want to bit bang SCSI and if you can find an interface IC like the NCR 5380 or, even better, the Zilog one those details will be taken care of and it will be a lot simpler.But there is still not all that much stuff around to actually talk to.QuoteI thought SCSI-2 was mostly about the move to wider busses which probably isn't all that useful for a Z80 system.QuoteI did say "if you are doing the handshake in software".If you can use INIR a Z80 can transfer one byte every 21t-states or about 190kB/s for the 4MHz partBut if you have anything where you are doing handshake in software it is going to drop quickly - if you need to poll a "byte ready" flag as with most floppy controllers then I make the loop about 60 t-states minimum which is 67kBytes/sec for the 4MHz part.However for the 2.5MHz part it is 41kB/s, and 33kB/s for a Z80 clocked at 2MHz - I remember trying to hook a 2MHz Z80 to an 8" floppy and found it impossible. Don't forget that your 5.3MHz part is a "fast" Z80.If you need to toggle more handshake lines during transfer it will slow down even more.QuoteYes, I saw that which increases the appeal, I admit.Did TurboDOS have subdirectories? - That was the biggest thing I disliked about CP/MQuoteOK, yes using SCSI to talk to a Raspberry Pi front end would certainly be doable and flexible.But as far as I am concerned I have absolutely no interest in hooking a Z80 to an RPi and having the latter just act as an I/O processor for the Z80. This is totally a personal view, of course and everyone is different but were I to built a Z80 system I would want it to be able to stand on its own feet.Quote from: Bruce Abbott on December 26, 2015, 02:16:22 amSee above, mostly - it would be nice if the system could sustain itself.Given that the sort of programs that one might write on a Z80 system are going to be minuscule by the standards of modern PCs the speed-up might not be all that large.That said I would probably set p a Z80 emulator running CP/M to do development work for the target.QuoteWhich is going to be true of any already extant OS.QuoteWhich is fine if copies of AMSDOS can be had online and there is enough documentation to port it to new hardware.I'm not so much suggesting CP/M3 because I think it is a good OS (it was functional) but because of the resources still in existence.QuoteAmen to that one.QuoteSounds like we actually agree on that one as well.

author: miguelvp
author_rank: Super Contributor
timestamp: December 26, 2015, 04:18:32 pm
content: Quote from: obiwanjacobi on December 26, 2015, 03:02:23 pmNot a problem I thought you were trying to use a 4 bit chip, but I see that's not the case.Quote from: obiwanjacobi on December 26, 2015, 03:02:23 pmYes it should be tolerant but to drive 5.0V CMOS devices they require a pull up resistor. But I didn't read it fully.Quote from: obiwanjacobi on December 26, 2015, 03:02:23 pmBad news on the Prototyping kit. Seems they tied up VDDD (digital) and VDDA (analog) together to a common VDD.Also all four VDDIOs are combined to a single VDDIO, meaning you can't really do level shifting between the 4 I/O domains as it's wired up. But I think you can still level shift between VDD and VDDIO, so you can use VDD at 5V and VDDIO at 3.3V if you need peripherals at that level.Of course you can always spin your own board, or maybe the freesoc2 (substantially more expensive) has all the power rails separate but I doubt it. I'm on my tablet at away from home so it's hard to look at more details.As for the software is really easy to use, and you don't even need to write verilog to use their already vast number of premade components. Pretty much you just need to drag them into the canvas and connect them with wires. Those components are also accessible to the Cortex M3 for any software control needs like interfacing blocks via USB to hook it up to your external computer.It also has 64KB SDRAM that you could use as the z80 memory, or at least to a portion of it, plus a 2KB EEPROM that could hold the z80 boot. I will have to look at more details because it's been a while since I used the z80 to see where the initial boot vector is at in the memory space and where the z80 starts executing on power up. I think it was on the upper memory but in any event it should be easy to map it.Of course it's not unlimited as in the number of pins available but I think it should be more than enough.They also have graphical modules to drive LCDs directly (up to 480x320) that interfaces with a graphical library (of course this will take some of the SDRAM)http://www.cypress.com/documentation/component-datasheets/graphic-lcd-controller-graphiclcdctrlBalancing things around I still think it will be very flexible and still allow growth for SCCI or other needs, within the pins limits, so optimizing the use might take some doing.Quote from: obiwanjacobi on December 26, 2015, 03:02:23 pmCongrats!

author: obiwanjacobi
author_rank: Super Contributor
timestamp: December 26, 2015, 05:18:17 pm
content: Z80 boots to $0000. There are several RST (Restart) instructions that call fixed routines between $0000 and $0038. There is the NMI service routine at $0066 and if you use Interrupt Mode 2 (IM2) the I register points to the upper address (A8-A15) where the interrupt vector table is located. IM1 just calls RST$38 (IM0 I will not use).I don't get why them tying the VDDs together will be a problem. I won't need the FPGA/CPLD anymore, so it can all be 5V.

author: miguelvp
author_rank: Super Contributor
timestamp: December 26, 2015, 05:24:05 pm
content: I did look it up, and the Z80 starts at address 0, the NMI forces a jump to address 0x0066, so the ROM can be on the first addresses. Usually on NMI it can fetch a value from a predefined memory address, then load that into HL and do a jump to that address, to keep it simple you can always jump to 0x0000Hah, was just postingEdit:It's not a problem per se, but having the flexibility of having different voltages on the analog or digital plus 4 separate digital I/O domains would give you more flexibility, for example have a two at 5V and the other two at 3.3V and be able to level shift within the SoC, or even put a 1.8V rail if needed.But I guess it's better they did that because otherwise the user will have to take care of having the right power rails defined.

author: Bruce Abbott
author_rank: Frequent Contributor
timestamp: December 26, 2015, 07:18:49 pm
content: Quote from: grumpydoc on December 26, 2015, 03:19:45 pmUnlike some other contemporary machines the Amstrad's OS was properly designedanddocumented. The system ROMs have also been disassembled, and there is an excellent simulator for it which includes a macro assembler and debugger.ROMs:-http://www.grimware.org/doku.php/documentations/repositoryFirmware guide:-http://www.cantrell.org.uk/david/tech/cpc/cpc-firmware/Disassembly:-http://www.retroisle.com/amstrad/cpc/Technical/firmware_cpc6128_os_rom_disassembly.asmhttp://www.retroisle.com/amstrad/cpc/Technical/firmware_amsdos_rom_disassembly.asmSimulator:-http://www.winape.net/OS documentation and disassembly listings are worth taking a look at just to see how they did it...

author: C
author_rank: Super Contributor
timestamp: December 26, 2015, 09:46:41 pm
content: Quote from: grumpydoc on December 26, 2015, 03:19:45 pmMight be worth your time to look at web for "Lobo Max-80"It's a Z80 at high speed that is a TRS80 model III clone but way better or a CP/M3 machine. Note that it has one rom of 512 Bytes that can boot from 5.25,8 or SCSISCSI-1All pins on SCSI-1 are open collector drivers like 7406.SCSI is bidirectional buss so you have inputs/outputs for all signals.You could think of this as a modified parallel printer port.Good Printer hardware would have a 8- bit status port and a 8-bit output port that is latched. Where a printer port uses a one shot that is triggered on output latch write, SCSI uses a FF ( SCSI ACK ).This output port has two addresses so A0 can change and is latched with the data (SCSI C/D ). Using one address you have Command level due to A0 while second address changes A0 to Data level. Very simple 9-bit output.When a device on SCSI bus reads the data the FF connected to SCSI ACK is reset.You have 2x 244, 2x 273, 74 & 7406'sThe nice thing here is the easy add of the C/D signal so that you can have two types of data & the hardware handshake.Quote from: grumpydoc on December 26, 2015, 03:19:45 pmSorry SCSI-2 is on two hardware versions "Fast SCSI" is 8 bits @ 10 MBs, "Fast Wide SCSI" is 16 @ 10 MBs"Note that there is many ways to go from 8 to 16 & 16 to 8 and be fast.Quote from: grumpydoc on December 26, 2015, 03:19:45 pmThere is some bits stored as the high bit of filenames. The directory actually contains subsets. See CP/M3 & TurboDos for this.With large hard drives, fairly common to have a utility to select different areas.The utility program is mounting an area of hard drive as a drive letter like you changing floppy's..Quote from: grumpydoc on December 26, 2015, 03:19:45 pmIf you can do all and can have a total of 8 counting the Z80 then you have a lot of choices. One is use very little or use less over time. You could let the Z80 pick what.In place of USB to serial where you add a serial port to Z80 at fixed speed, you could have a processor doing this function and no serial port on Z80. This processor could then give you a lot more. How about a Debug terminal and printer port. Could act like a Flash drive making a file move easy.What about a quick and easer interface to "SD cards"? Newer controllers make this easer and cheap.Quote from: grumpydoc on December 26, 2015, 03:19:45 pmThere is a Z80 emulator running TurboDos.@obiwanjacobiThis may help you some.A processor like the 68K which is 16-bit wants two parallel banks of 8 bits so that it can write a byte or two bytes.To match up with a Z80, The Z80 would be using A0 to select a bank.If you think of what then happens to memory, the Z80 would be switching banks as the instructions are read. A 16-bit operation would use one bank then the other.If you are wanting to have dual port memory, you just opened a 50% window.Said a different way your two 64kx8 chips would have memory A0 connected to Z80 A1 and so on for remaining address lines. Z80 A0 would become part of memory CE. The 68k would use the 16 data in parallel and to be compatible with this, The Z80 would need an additional transceiver. Staying 8-bit wide the transceiver would not be needed.This can be used many places. Going wide with cache is a help in increasing memory speed.

author: grumpydoc
author_rank: Super Contributor
timestamp: December 26, 2015, 11:21:46 pm
content: Quote from: C on December 26, 2015, 09:46:41 pmSome of my earliest programming was on a TRS-80. Sadly I never developed much love for the machine.QuoteIf we'd been having this conversation 25 or 30 years ago I would have agreed that adding a SCSI interface was the right thing to do. I started to try to design one for my Nascom but never finished it.Today, I think we will have to agree to differ on this point.QuoteI never used CP/M3 - it came just a bit after I'd moved on from Z80 systems but looking at the CP/M3 documentation it looks as though it is no different from CP/M 2.2 - just one directory per disk.I think it would be worth listing the alternatives.QuoteAs has been observed this would have to be a "for fun" project and everyone's idea of how to do it will be different - and mostly equally valid.If I were to implement a Z80 system today, just to play with one, I would want it to be fully stand alone. Using an FPGA for serial I/O or even video would be fine but using a vastly faster general purpose SBC as a front end just would not feel right - however useful it might be. It so happens that I would not have a clue about using an FPGA so I would go down the discreet logic route.Iwould, almost certainly look at one of the more modern Z80 lines such as the 64180, Z180 or ez80 though, together with modern high density SRAMS It should not be that difficult to build a system which would run rings around anything that could have been built in the 1980's without loosing the "genuine Z80" feel.

author: BloodyCactus
author_rank: Frequent Contributor
timestamp: December 27, 2015, 02:43:29 pm
content: well talking scsi + z80...Zilog was a second source for the very famous NCR 5380 scsi chip. Zilog ones come in PLCC or DIP! Its a full SCSI controller in a chip. It does afaik 3mbs? can still get these chips all over ebay etc. a very very popular chip. lots of documentation around for them.

author: C
author_rank: Super Contributor
timestamp: December 27, 2015, 05:37:45 pm
content: With a NCR 5380 or some other scsi controller,What do you gain and what do you lose or has greater cost?A write sector to a scsi device is two blocks of data with the C/D signal changing between the two blocks. The C block(command block) is different sizes and is often in different area of memory from where the D block(data to write) is located.Not hard to do in software but if DMA is used is two DMA transfers with something to change C/D state between the two.So from the very simple hardware where processor does it all, you start adding the controller init code and then even more code to remote control the controller.For what I am trying to say, you do not have to match SCSI, just a lot of it's capabilities.9- bit data or hardware way of separating 8-bit data into at least two categories.Send bidirectionally with speed control to prevent overruns.Multi-host, While this sounds complicated, it can make things a lot easer and faster.The SCSI controller chip can make some parts a lot slower. It was built with delays for long cable connections.Think of all the ways that this can be done easily with low software overhead. Async 8-bit serial has been used to send/receive Ethernet or IP packets, but has a very high software overhead to do it. Sync serial with it's bit stuffing makes this easy.Todays fancy async serial controllers make sending 9-bit data hard and has limits. With some of the initial serial controller chips this could be easy.It's the idea, scsi just contains the parts needed for a parallel buss.

author: BloodyCactus
author_rank: Frequent Contributor
timestamp: December 27, 2015, 09:45:13 pm
content: well, I never brought scsi up to begin with, but if someone is going to start messing with scsi and try to implement it, I was just pointing out you can get nice friendly pinout (plcc/dip) chips that handle the scsi interface. and hey, even zilog got on the 5380 bandwagon. personally, I wouldnt try and bitbang scsi, like I would not try and bitbang gpib. interface chips exist to help simplify using the protocols.

author: C
author_rank: Super Contributor
timestamp: December 27, 2015, 11:38:15 pm
content: BITBANGShows one difference of a micro controller and a microprocessor. With a microprocessor you have two nice signals that happen when a port is read/written that can be used.With a micro controller you have to bitbang a parallel printer port.With a microprocessor and good hardware you just write to parallel printer port, hardware does the strobe.scsi & gpib were built to work with simple 8 bit microprocessors and be cheap in hardware.

author: timofonic
author_rank: Frequent Contributor
timestamp: December 28, 2015, 01:24:01 am
content: If you manage to do the hardware (In sure you'll finally manage it!), please consider a port ofFUZIX. It's a resurrect of a 8 bit by l long time Linux kernel hacker Alan Cox.I it's an UNIX-like OS, but 16bit and MCUs are taken in consideration too. There's MSP430 port too.

author: grumpydoc
author_rank: Super Contributor
timestamp: December 28, 2015, 11:22:05 am
content: Quote from: timofonic on December 28, 2015, 01:24:01 amThanks for that link - looks really interesting. I was aware of UZI and even have the source code stashed somewhere but it's a long way from a set of source code to a working system.

author: obiwanjacobi
author_rank: Super Contributor
timestamp: December 30, 2015, 01:20:56 pm
content: Beh, I just discovered my Altera Max II (244) is way too small for what I want to do (not in pin count though). Almost completely filled it with the Memory Management Registers (RAM) alone (> 70%).

author: Ian.M
author_rank: Super Contributor
timestamp: December 30, 2015, 02:24:34 pm
content: That's why you should use a '486 era cache ram for the page address translation. Then all the CPLD has to do is provide the glue logic that lets the Z80 read and write the page translation tables via a couple of addresses in its I/O space.

author: legacy
author_rank: Super Contributor
timestamp: December 30, 2015, 03:07:56 pm
content: the PCB goes complexI suggest to have a look atArtyboard

author: obiwanjacobi
author_rank: Super Contributor
timestamp: December 30, 2015, 04:34:54 pm
content: External (to the cpld) cache memory would require for normal operation (assuming 4k pages):CPU MEM Sys: Mapped AddressesA12-A15 => | |MEMREQ => | D0-D7 | => MA12-MA19RD/WR => | |To configure the contents of the cache (assuming same content for RD and WR and starting IO address $00):CPU MEM SystemA0-A3 => | |IOREQ => | D0-D7 | => D0-D7RD/WR => | |(Decoding to Cache-CE not drawn)That would sort of boils down to that I need to isolate the entire memory chip. That would eat up a considerable number of pins on the CPLD. Is this what you had in mind or am I missing something here?

author: C
author_rank: Super Contributor
timestamp: December 30, 2015, 05:19:13 pm
content: Firstswitching signals takes time. be good not to have delays like this for normal use.Look at InstructionOUT (C), rC -> A0-A7B -> A8-A15r -> D0-D7One transiver to connect Z80 D0-D7 to memory chip D0-D7 durring updateOne latch for High address of memory chipZ80 A15 down to map size direct to memory chip low addressC

author: Bruce Abbott
author_rank: Frequent Contributor
timestamp: December 30, 2015, 05:19:39 pm
content: Quote from: obiwanjacobi on December 30, 2015, 04:34:54 pmSorry if this a dumb question but what exactly are you trying to do, and why do you need 'cache' memory?

author: grumpydoc
author_rank: Super Contributor
timestamp: December 30, 2015, 05:40:25 pm
content: Quote from: Bruce Abbott on December 30, 2015, 05:19:39 pmThe aim is to extend the Z80 address bus by 4 or 8 bits (to 20 or 24 bits).To do this you need a fast RAM - I have previously used a pair of 74F189's which are handy as they have separate data in and data out lines which makes connecting it up slightly easier.But any fast (10ns or so) RAM will do and 256k x 8 10ns SRAMs are readily found as the L2 cache on an i486 or early pentium motherboard.

author: Ian.M
author_rank: Super Contributor
timestamp: December 30, 2015, 10:50:03 pm
content: I described the support logic for I/O mapped reading/writing a W24257A 32Kx8 SRAM used for page address translation in some detail back inpost #34. My conclusion was: one 8 bit latch for translation table selection, and one bidirectional tristate buffer to get the data bus to the W24257A data pins during I/O operations to it, + a chunk of glue logic that shouldn't take too many extra CPLD pins *IF* you are already monitoring the whole Z80 bus to implement a fully featured debugger. If not, you may want to do some I/O address decoding outside of the FPGA.

author: obiwanjacobi
author_rank: Super Contributor
timestamp: December 31, 2015, 12:42:16 pm
content: Ah right, I thought it was mentioned but couldn't find the post.So the IO address for configuring/switching will also be above the 4k address. That would require the use of that one OUT (bc) instruction, but that would work.I have looked into what cache memory to choose(I could not find the type you mentioned) and obviously need 74F series to keep overhead to minimum (what is the difference between all the octal bus latches with tri-state outputs!?).

author: Ian.M
author_rank: Super Contributor
timestamp: December 31, 2015, 01:52:05 pm
content: You need to make sure the cache ram you use does *NOT* latch its address bus - i.e. it will operate with /CS and /RD held low, and update its data bus to reflect any address changes. I suggested the W24257A because it supports this unusual access mode.You need to check the datasheet of your chosen chip to confirm it does also.If you add logic to remap the address lines to support easier block loads, use analog switches for minimal propagation delay when in address translation mode. The 8 bit page table latch and the bidirectional tristate buffer for the databus are not in the direct path for translated address propagation delay, so 74HC logic should be fine.

author: timofonic
author_rank: Frequent Contributor
timestamp: December 31, 2015, 04:28:32 pm
content: Quote from: grumpydoc on December 30, 2015, 05:40:25 pmAre there a list of them? I have a bunch of old broken motherboards and computers getting dust somewhere, maybe there are enough of that to share.

author: C
author_rank: Super Contributor
timestamp: December 31, 2015, 08:18:58 pm
content: Found this data sheet forGLT725608-15J3http://pdf.datasheetcatalog.com/datasheet_pdf/g-link-technology/GLT725608-12FB_to_GLT725608-20TS.pdfOn page 5 look at READ CYCLE 1 (1,2,4)NOTES:1. WE is High for READ Cycle.2. Device is continuously selected CE ? VIL.3. Address valid prior to or coincident with CE transition low and/or transition high.4. OE ? VIL.A new data output = new address input delayed by Taa time. Taa = 15ns maxwith WE = high, CE & OE = lowThis should be what lan.M is talking aboutC

author: Ian.M
author_rank: Super Contributor
timestamp: December 31, 2015, 10:32:25 pm
content: Yes. that's the access mode you needCache RAM in the late 386 to early Pentium era was frequently socketed - 0.3" pitch PDIP - 28 or 32 pin for the cache itself in multiples of 4 and often a 28 pin cache tag RAM. If your scrap motherboard has socketed chips near the CPU that match this description, put the part numbers into google to see what they are. Beware of soldered in fake cache on some PC Chips motherboards (almost always accompanied by a soldered in BIOS and other signs of cheap&nastyness).

author: timofonic
author_rank: Frequent Contributor
timestamp: January 02, 2016, 07:51:06 am
content: 15n and 20n? I'm too tired and lazy now, I'll look later and check all my old trash too

author: obiwanjacobi
author_rank: Super Contributor
timestamp: January 02, 2016, 04:07:16 pm
content: I always thought that all memory devices worked like that...

author: jwm_
author_rank: Frequent Contributor
timestamp: January 05, 2016, 03:39:54 am
content: Quote from: obiwanjacobi on January 02, 2016, 04:07:16 pmFRAM chips require toggling the ce pin to latch each address even though they are otherwise pin compatible with standard sram. Can be annoying or useful depending on your application,

author: obiwanjacobi
author_rank: Super Contributor
timestamp: March 09, 2016, 09:51:44 am
content: Hi I'm backI am looking at designing the bank switch circuitry and am reading back what was said about it:Quote from: Ian.M on December 30, 2015, 10:50:03 pmIn Post #34 there are a couple of sentences I don't get - now I am really designing it..Here the relevant paragraph with the text highlighted.Quote from: Ian.MTake them one at a time:QuoteI think this should be the memorydatabus!?QuoteI put this on the memory data bus in my design to retain the high memory lines (MA12-MA19).QuoteWhy a single address? And what is this IO address for?QuoteAlsoQuoteI have not done yet. To be honest I don't see the need... There is OTIR and OTDR - both with the same number of cycles etc...?I have not added the Latch for quick selection of extra page banks yet - I think that is clear how I should do that.The design that I have now is attached. I have tried to write the logic equations for each signal that has to be decoded.

author: Ian.M
author_rank: Super Contributor
timestamp: March 09, 2016, 05:04:39 pm
content: I'm looking over my notes. IMHO, here's how the bus handling should look. I haven't dealt with the glue logic yet nor checked your logic equations.Note that the 74F573 separating the address translation RAM W24257A DIO pins from the high 8 bits of the memory address bus is NOT needed or desirable. During I/O space reads or writes, it doesn't matter what's on the memory address lines as their /CS pins are inactive because /MRQ is inactive. During memory space accesses, /IORQ is inactive so the 74HC245 is disabled and dosn't conflict, so the RAM can drive the high 8 bits of the memory address bus directly. If you have a fanout problem, fast 'dumb' non-inverting buffers may be needed where the 74F573 was but you don't need to tristate the memory side and certainly don't need a transparent latch there as the extra propagation delay cuts into your memory cycle time.The two 74HC573 chips I've added on the right are for swapping page tables. Both are written at separate decoded I/O addresses. Their output enables are to be driven from /IORQ and !/IORQ respectively (use an XOR to balance the inverted and non-inverted propagtation delays). The one enabled by !/IORQ controls which page table in the W24257A is active during memory accesses. Its decoded off !/IORQ not/MRQ to give the W24257A the longest possible address setup time to minimise the impact on the memory cycle time. The other one is to control which page table gets read/written during an I/O space access to the W24257A.You'll need to do something with /MEM-RD. During I/O accesses it needs to be connected to a Z80 address line so the page table read/write code can choose between accessing the different memory read and write translation tables. At all other times it needs to connect to Z80 /RD, again to minimise the propagation delay. I suspect an analog switch chip is the best way to select this signal.

author: obiwanjacobi
author_rank: Super Contributor
timestamp: March 09, 2016, 06:06:15 pm
content: First of all what an awesome copy-paste job on that drawing. Really excellentQuote from: Ian.M on March 09, 2016, 05:04:39 pmRight. I got it in my head that the program would crash if I did not maintain these memory address lines. I am not sure how the repeating instructions work on the Z80 but I think I read somewhere that the Z80 fakes the repeating by decrementing the PC and rereading the same instruction again...? Anyway I understand what you're saying (I think) and I realized the extra propagation delay as soon as I placed the latch on the data/address bus - I remember thinking 'is this correct?' - that's why I came back here to ask/discuss.Quote from: Ian.M on March 09, 2016, 05:04:39 pmYep got it. This part was sort of clear in my head - although I didn't think the IO access through all the way yet. If the latch is on all the time (unless /IOREQ is active) then it is also decoding data when the /REFRESH is done (after the instruction fetch). Not sure if the data bus is hi-Z at that time...?Quote from: Ian.M on March 09, 2016, 05:04:39 pmThat is why it says on my drawing 'IO?'I don't see how connecting /MEM-RD to just the Z80 /RD would work. I would figure that that would screw up bank/page selection on input and output instructions...?I was thinking that we could use one output of the IO-active latch to address it for setting up (instead of D7 for instance). In normal mode the other latch would have thedecoded /MEM-RD (or !/IOREQ & /RD)/RD signal on its input (also instead of D7). That would still leave 128 banks/pages to play with -more than enough I would think. (did I get this right?)- never mind

author: C
author_rank: Super Contributor
timestamp: March 09, 2016, 06:22:03 pm
content: Ian.MThink you left out one important point.At Power Up the contents of the RAM chip is Unknown.Need to have a safe memory space for a power up program to set the initial contents of this Ram chip.Adding resistor pull-ups to the data output of ram chip and disabling Ram OE will allow the extended address bus to become logic high.The Z80 at Power-up reset would start running a program at 0000H. The actual program would come from extended address of FF000H due to the pull-up. When Z80 has initial data contents in the Ram, Ram OE returns to normal for /MREQ use.If this is not done then the Power-up reset program needs a direct connection to Z80 address buss.

author: Ian.M
author_rank: Super Contributor
timestamp: March 09, 2016, 06:49:24 pm
content: Quote from: C on March 09, 2016, 06:22:03 pmYes, I covered exactly this in reply #34:Quote from: Ian.M on December 14, 2015, 12:53:33 pm

author: Ian.M
author_rank: Super Contributor
timestamp: March 09, 2016, 11:16:32 pm
content: I don't see the issue with /RFSH. If you aren't supporting DRAM, it really doesn't matter what the upper 8 bits of the memory address bus are doing during it. If you *ARE* supporting DRAM, then the upper byte of the Z80 bus gets the contents of the I register during /RFSH, which is not particularly useful so the upper eight bits of the memory address bus are probably 'don't care' so it doesn't matter how they are translated. The R register gets passed to the memory on the lower 7 address bits anyway. Its interesting to consider Mode 2 interrupt vector fetches as the I/O space table select latch will get activated, but as neither /RD nor /WR strobes, there is no risk of a W24257A or table select latch update or of a bus conflict. Obviously I/O devices must be on the Z80 side of the W24257A, not on the translated memory select bus.If you are planning to support DMA via /BUSRQ, then you either need to switch /BUSACK to one of the spare currently grounded address lines of the W24257A, so that a DMA translation table can be set up and used, or let the DMA controller drive A16-19 directly and add logic to bypass the W24257A for A12-15 while /BUSACK is active.I'm definitely in favour of keeping the limited I/O address space as clean as possible, and for efficient paging, one needs to give up a whole single byte I/O address (i.e. OUT A,(nn)) to write the 74HC593 decode table select latch U1 for fast selection of one of 256 pre-loaded page address translation tables.Due to the fast selection, my comments in the early pages of this topic about switching the W24257A upper address lines around when updating it in the I/O address space to permit efficient use of OTDR, are no longer so critical apart from the /MEM-RD signal.You *could* simply save on hardware and only switch /MEM-RD to a high address line. However for the price of an extra 74HC4053 triple SPDT switch (you already need one for /MEM-RD) + a 74HC138 3 to 8 line decoder, you can rearrange + fully decode the high byte of the address bus, which lets you share the low address byte with the 74HC573 update table select latch U2, and up to 6 other peripherals + permits fast table loading with OTDR*. I think the benefits are worth the extra chips.* Yes you could use OTIR, but as that increments HL and decrements C, its more confusing than decrementing both, and would require the page table to be in reverse order before loading. If you don't rearrange the address lines during I/O accesses, the page tables have to be loaded one byte at a time which will be more and slower code.N.B. If you are going to add a debugger with hardware assistance, you may need to implement read-back of the two 74HC593 chip outputs so the debugger/monitor ROM can determine the current paging settings. However a non-invasive NMI based hardware debugger gets quite complex, especially if it preserves the user stack untouched and you may settle for a simpler scheme where all paging must go through a BIOS call that shadows it in RAM to be tracked and that requires the NMI vector in the current page 0 to contain a jump to debugger code in the BIOS ROM.

author: obiwanjacobi
author_rank: Super Contributor
timestamp: March 10, 2016, 05:02:56 pm
content: Yes the boot-up is something I have to look at still.Quote from: Ian.M on March 09, 2016, 11:16:32 pmI currently have a 'system controller' that manages loading the bios into memory (DMA) - I have no ROM. The System Controller can take control of all the CPU lines (after BUSREQ/ACK) it can also read or even change the address mapping RAM. So I think I would prefer that the high memory address lines are also high-Z...Quote from: Ian.M on March 09, 2016, 11:16:32 pmI have a CPLD (Altera MAX II) -with some level shifters- that will do all the decoding for the system or I will use a GAL for separate boards that need decoding logic. That is why I focus on the equations of the logic of these signals.Quote from: Ian.M on March 09, 2016, 11:16:32 pmI have to sort this out. I cannot reason about it now from the top of my head...Quote from: Ian.M on March 09, 2016, 11:16:32 pmI am planning on building some debugging facilities. To what extent, I am not sure yet. I was thinking of using the HALT instruction and the NMI to stop the program, grab the CPU state (already have written some code to try out later) and then continue -either directly or by user command. Again the System Controller will play a major role and can examine the RAM when the CPU is halted. Because the System Controller can take over all CPU lines (after BUSREQ/ACK) it can also read or even change the address mapping RAM. But it cannot read the values of the latches. It may be nice to be able to read back those address line values...Also, all system functionality goes through the BIOS. So a program does not 'know' how it works, it just knows what bios call to make to perform a certain operation. Tinkering is not allowed!

author: Ian.M
author_rank: Super Contributor
timestamp: March 11, 2016, 12:53:20 am
content: The advantage of the analog switches rather than a GAL or FPGA or even discrete logic is the extremely low propagation delay from common to either switch pole. e.g. a 74HC4053 can pass a 170 MHz signal and it will only be 3dB down. If you are careful with the routing between the 74HC4053 common pin and the W24257A address pin, you can expect a propagation delay of only a few ns. As any delay directly eats into your memory cycle time, if you are planning on running the Z80 as fast as possible, its cheaper to keep the FPGA/PAL out of the most timing critical signal paths rather than have to buy all faster memory.

author: obiwanjacobi
author_rank: Super Contributor
timestamp: March 13, 2016, 06:50:39 am
content: Got it - thanx.

author: Ian.M
author_rank: Super Contributor
timestamp: March 13, 2016, 08:15:14 am
content: Of course, if you are using a GAL or FPGA for other purposes, it makes sense to use it to drive the control pin of the analog switch. Just be careful of the propagation delay from control to switch activation as it is much worse than for a signal straight through the switch. If you fully decode the I/O address to activate the switch, you may well need to add a wait state.

author: obiwanjacobi
author_rank: Super Contributor
timestamp: March 13, 2016, 08:25:33 am
content: I believe IO has an extra wait state by default - so we may be good there...But I haven't ran the numbers yet...

author: obiwanjacobi
author_rank: Super Contributor
timestamp: January 06, 2019, 10:12:59 am
content: I know this is an old post, but I thought this info might be useful to someone reading this discussion....I recently did some more work on my Zalt Z80 homebrew computer project and ran into a snag.This is the MMU I have on my Z80 boardThe problem lies in the timing of the Load (LE) signals of U101 and (possibly) U102.These signals are generated by a CPLD (MaxII) that contains all system logic.It uses an address decoder and the IOREQ and WR (out instruction) to activate a specific latch, either U101 or U102 - never both at the same time.If we look at the Z80 IO timing diagram for in and out instructions you can see the IOREQ and WR lines go inactive at the very last moment. Problem is that the 74HTC573 latches that I'm using use the transition of Load (LE) from H to L to latch in the data, which at that point may not be stable at sufficient clock speeds.(also at lower clockspeeds I see the same problem)I run into problems at clockspeeds of around 8MHz. Lower the clock speed (to around 4Mhz) and it is fine.The74HTC573only needs a few (<10) nanoseconds to grab the data.I have noticed that when I hook up my (cheap) logic analyzer to the Load/LE pin of U101, it works again. Probably because the added capacitance delays it just enough? I'm not sure - at that point it starts to get hazy.Anyway I just wanted to share this - this design has issues!(then again it may also be software issue where I goofed up somewhere)

author: fchk
author_rank: Frequent Contributor
timestamp: January 06, 2019, 11:34:51 am
content: When I went to school there was the NDR Klein Computer. There were TV shows in German TV, there were books, and there is still a web site:http://www.ndr-nkc.de/compo/index.htmhttp://www.nkc-wiki.de/index.php?title=Hauptseitehttps://www.amazon.de/Rechner-modular-Computer-selbstgebaut-programmiert/dp/3772387217/ref=sr_1_1?ie=UTF8&qid=1546774411&sr=8-1&keywords=3772387217They have everything - also monochrome and color graphic cards.

author: Ian.M
author_rank: Super Contributor
timestamp: January 06, 2019, 11:41:40 am
content: I'd take a very careful look at the CPLD's logic equations for those signals as additional loading on the LE (Load) signals should make the timing worse, not better. If you haven't pooched the equations, you may need to limit their active time by counting Z80 clock edges from their leading edge to get a longer data hold time for the latches. Hopefully you've got enough capacity for a few flipflops left in the CPLD.

author: obiwanjacobi
author_rank: Super Contributor
timestamp: January 06, 2019, 01:13:04 pm
content: It looks like the latch is triggered at the moment I write data (U103) into the RAM.Eitherthe CPLD equationsare incorrect or there is a hardware problem that makes the U101-Load (LE) line float at that time (and trigger). That would also explain why hooking on a logic analyzer probe would solve the issue (pull up?)...Because my 5V tolerant MaxII circuitinvolves pull up R's I'll go check if there might be missing one...Edit: No pull ups missing. Putting a probe on U101 OE and none on Load also makes it work...

author: obiwanjacobi
author_rank: Super Contributor
timestamp: January 06, 2019, 02:26:21 pm
content: The routine I use to test this with probes the extended memory to look for valid 4k pages. It maps a page into a known area in the CPU memory and test if it holds onto what is written to it. The routine starts off with setting the U101 and U102 latches to the same value (0 in this case) and read the page data that is currently in the mem-map-ram for the spot that is to be used as test spot.In the 'working' scenario you can see these three IO operations (bottom left). You can also see the U101 Load (LE) at the top left.BTW: ch3 was not connected.After that a loop is entered to map all possible pages into that test spot and probe it. Those IOREQ's are the out instructions to write new data into the mem-map-ram to switch a new page into the test spot.Notice that 101-q1 is stable throughout - as the latch is not triggered again, it retains its latched values.When I disconnect the probe from U101 Load (LE) we see a different picture. We see the same IO in/out pattern as before -because we're using the same test program, but U101-q1 is not stable. Apparently the U101 latch is triggered with each write to the mem-map-ram.When I put probes onto U102 Load (LE) and OE it does not fix the problem, so it seems concentrated on U101.Edit: I've tried the same scenario on a very low clock speed (500~600kHz) and it is not fixed. That suggests (to me) that is is probably a logic error. If it were a timing issue, would it still persist at a 10th of the orignal speed?What I still don't understand is why putting a probe on U101-Load or U101-OE fixes the situation??Edit2: Putting a 10k pullup on the U101 Load (LE) fixes it... Now I want to understand why?