Will Sowerbutts

Members
  • Content count

    11
  • Joined

  • Last visited

  • Days Won

    3

Community Reputation

3 Neutral

About Will Sowerbutts

  • Rank
    Member

Profile Information

  • Gender Male
  1. Alan I agree running it in a state where the synthesiser says "yes, I'm confident that can work!" would be preferable I'd love to really understand why the timing error exists at 128MHz and what I can do to change the design to meet timing. The breakage is almost certainly in the DRAM. At a slower clock speed the data from the DRAM arrives at the input pins in fewer clock cycles. I think that you can just tinker with the length of the "data_ready_delay" vector in SDRAM_Controller.vhd to adjust when the data is read. You need to reduce its length from 5 down to 2 or 3 bits, I expect. To test in the monitor: Write a value to RAM, then read a value from another address that aliases to the same cache line (eg addr+16K), then read back the first address you wrote to. Will
  2. Sounds interesting, I look forward to seeing this!
  3. Alan http://sowerbutts.com/8bit/vgatext.zip This is the relevant code from my earlier 6502 project. The "video.vhd" file ties it all together. It's even older than socz80 so the code is yet worse! It should be easy enough to adapt to the bus signals that socz80 uses. Requires a 64MHz clock (vga_pixel_clk) which you can easily get the existing PLL in socz80 to generate on one of the unused outputs. The 0th entry in the font ROM should (arguably) be an empty space but for my testing I redefined it to a symbol with clearly indicated corners. The four corner characters of the character memory are initialised to 0 and this makes it easy to check that the corners of the video signal appear correctly ie that the video timing is correct. Will
  4. Alan I have code from an earlier project that generates VGA at 1024x768. It uses a character generator and 8x16 font to draw 128x48 character text mode at this resolution. There are no frills, the CPU is responsible for shuffling characters about in memory to scroll the screen etc. The display memory uses dual ported block SRAM with one port for the character generator to read out data while drawing the screen, and a second port for the CPU. Dual ported RAM is exactly what it sounds like; one set of memory cells that can be read/written concurrently through two independent ports. Each port is synchronous to an independent clock so this is one way to get information safely from one clock domain into another. If you search for "Xilinx UG383" you'll find a technical reference with plenty of detail about how to use the Spartan-6 on-chip block RAMs. Should be easy to integrate with socz80 if you're interested; just instantiate the hardware blocks and map the additional SRAM into the CPU's address space (there's plenty of address space reserved above 16MB for this). Let me know if you'd like a copy of the code. Will
  5. Wow! One of my heroes!
  6. z88dk: Yes I did. I concluded sdcc was better for my requirements.
  7. Hi offroad, I expect the ZPU performance would be higher; the Z80 wastes several cycles each instruction performing refresh cycles for DRAM. I did wonder if the Z80 core could be modified to omit those cycles, I think it could but this is a project for another day. Your ZPU data path is four times wider so also a big advantage. The flat 32-bit address space would certainly be a preferable model for the programmer! I use SDCC to cross-compile my UZI kernel. Works well. I have some tools that postprocess the linker output to build the final kernel executable that can be loaded from CP/M and then a little stub program juggles things around in RAM until they occupy the required addresses. Be warned that marking a function with "__critical" is buggy and will smash up the stack, but it works fine for a critical section inside a function. SDCC assumes the compiled executable will live in ROM and so any initialised variable is allocated space in ROM (for the initial value) as well as space in RAM, and a chunk of code at startup copies from one to the other. Not a problem for small programs and I think probably simple to patch the compiler or even do a bit more postprocessing of the linker output. Will
  8. alvieboy -- there's more than 32KB of block RAM on the FPGA that remains unused. I had been saving this for video memory because the block RAM is dual-ported. You can use one port for the CPU driven by the 128MHz system clock, and the second port for the video circuit driven at whatever clock speed the video timing requires.
  9. Thanks guys, I had a lot of fun (and quite a few late nights!) making this. Mike -- your FPGA tutorial got me started, and you SDRAM controller has been utterly invaluable to me. Thank you!! Best wishes Will
  10. Hi everyone. Last year I wrote a Z80-based retro microcomputer which runs in the Papilio Pro. It started out small but I added a few interesting features, in particular a memory management unit and a 16KB cache to hide the SDRAM latency. I've ported several operating systems to it. Both the hardware and software aspects of the project have been good fun with lots of new opportunities to learn. I've just made my first public release, you can download it at http://sowerbutts.com/socz80/ and try it out. That page also describes the project in a bit more detail. RAM disk images are included to boot CP/M-2.2, MP/M-II and UZI (a UNIX system). I've included Zork and the Hitchhiker's Guide game which will play under all three operating systems; they are native CP/M application but MP/M-II implements the CP/M system calls, and UZI includes a CP/M emulator. The release also includes the full VHDL source code for the machine and the source code to all the software I've written, with the exception of the UZI port which I plan to release shortly after I extend it to support the N8VEM Mark IV SBC. Please let me know if you get it to work! This post has been promoted to an article
  11. The original forum post is here. The project page is here. Hi everyone. Last year I wrote a Z80-based retro microcomputer which runs in the Papilio Pro. It started out small but I added a few interesting features, in particular a memory management unit and a 16KB cache to hide the SDRAM latency. I've ported several operating systems to it. Both the hardware and software aspects of the project have been good fun with lots of new opportunities to learn. I've just made my first public release, you can download it at http://sowerbutts.com/socz80/ and try it out. That page also describes the project in a bit more detail. RAM disk images are included to boot CP/M-2.2, MP/M-II and UZI (a UNIX system). I've included Zork and the Hitchhiker's Guide game which will play under all three operating systems; they are native CP/M application but MP/M-II implements the CP/M system calls, and UZI includes a CP/M emulator. The release also includes the full VHDL source code for the machine and the source code to all the software I've written, with the exception of the UZI port which I plan to release shortly after I extend it to support the N8VEM Mark IV SBC. Please let me know if you get it to work!