• Content count

  • Joined

  • Last visited

  • Days Won


Posts posted by EtchedPixels

  1. If you are memory constrained then the *nix to port would probably be 2.11BSD on PDP-11 (aka RetroBSD on MIPS in a more recent incarnation). Linux is not optimised for size but for performance on modern PC class hardware. 2.11BSD was designed to run with full networking on a system with 1MB of RAM. 11 code is tighter than ARM though.


    Other "micro Unixen" include UZI (aimed at Z80 mainly), OMU (originally intended for 68K), and ELKS (8086). Plus these days Minix is free so I guess you could run Minix on an 8086 FPGA core 8)


    To me the more interesting questions are things like "How much of the OS can you turn into raw FPGA" - eg having instructions for 'reschedule', 'zero page', 'syscall', some of the file system elements and other hot paths.



  2. You don't need hardware cache coherency for SMP. At minimum you need an inter processor interrupt scheme and cache invalidate/cache flush instructions. The rest can be done in software. x86 has hardware coherency but many other platforms do not and implement it in software via the MMU (catching write faults).


    There are lots of reasons to do it in hardware (including not having all the programmers hating you!) and in many cases you can do the L1 cache lookup (private local cache), MMU walk and the coherency protocol in parallel.


    There dual ported RAM on the spartans always looked ideal for doing a BFI (Brute Force & Ignorance) shared cache implementation and Will did use it this way for one of his SocZ80 experiments.


    There are some other ugly cases to watch - processors modifying each others instruction stream as you decode, processors updating shared MMU tables and so on.

  3. IMHO


    1. Memory is cheaper than SSD - if your box is slow then more memory can be a bigger help (assuming you are running a 64bit OS at least)


    2. SSDs need good backups. Hard disks often give you a hint they are going to die, or have the decency when they die to just expire on the spot. SSDs rarely give you a hint, and sometimes die a rather horrible drawn out death where they do things like quietly eat your data without telling you.


    They are getting better but with an SSD you need to be doing all things you are *supposed* to be doing for hard disk backups...

  4. Not had time to play with the slower clock yet as a mix of real work and packing keeps getting in the way.


    Text mode video is now working and I have a VT52 console on SocZ80 with a few small extensions for 40/80 columns etc. Still need my boss to return to get the paperwork done. It's alarming how well you remember processors you learned when about 12. I can still sit down and churn out Z80 without thinking !



  5. Thanks I'll give that a go.


    I did start reading some of the guidance on fixing timing delays but its mostly over my head at this point. That said if the CPU and cache can be clocked at 128MHz I doubt clocking the rest at a lower speed would be noticable in performance ?


    On the bright side a minimal video console is now working (only 80x25 chars, almost no control codes). That's enough to make the I/O handling that slight bit slower and enough to break sendmany with an overrun. Meh


    I've mapped the video into bank 1 0x7000-0x7FFF and told CP/M the bank space available is 0100-6FFF (with CP/M 3 banked

    itself running above that again). That means a bank switch on console I/O to the monitor but it also means the entire terminal emulation can live in banked RAM so won't intrude on the TPA.


    Some interesting oddities left to deal with - 'trapdoor' and then rboot 200 makes a nasty mess as rboot doesn't force the MMU back sane, and due to the banking "uzi" and "mpmldr" both fail because they are somewhat surprised when they bank switch to discover that they were not in bank 0 and just entered hyperspace. uzi also dies because the SPI is now connected to the ADC and that upsets it greatly 8)


    I have been trying to work out some kind of concept for actual platform so I don't have 500 CP/M BIOSen to field at the moment I've added the following to the memory and I/O map


    0x201xxxx    => Video RAM


    0xE0 => Feature bits (uart 0, uart 1, sd card on 0x30, joystick 0, 1, 2, vga out, ps/2 in)

    0xE1 => Feature bits2 (audio out)


    0xEC => Joystick 0

    0xED => Joystick 1

    0xEE => Joystick 2

    (These will be mappable as AUX input in CP/M 3)


    0xD8-0xDF => Video (with 0xDF identifying the device present if any)


    0x80-0x87 => Wing #0  (and  I guess we'll need some for mixed setups)


    Right now it just consists of identifier 0xFF (none), 0x01 (Logic WIng), in which case the I/O ports drive the seven segments


    For the logic wing the switches are mapped to the GPIOs (and switch 0 is reset), and the LEDS to the GPIO outputs (with LED 4 hardwired to cpu wait at the moment as before).


    Need to have a look at the clock divider some day too, although I'm thinking it may well be sufficient for many uses to tell the BIOS that if switch 2 is set it should spin each character output as if it were at 9600 baud. That'll probably make many games work ok!



  6. Much strangeness going on.


    I tried dropping it to 64MHz but then the DRAM or cache breaks somewhere (eg rread 200 fails part way with a random address change). I set the clock divider 0 to 8 (from 4) and also  adjusted clk_freq_mhz. If I remember correctly Will you said you'd run it at a lower clock when trying to make SMP work. Were there any other bits of magic needed that aren't in the base source ?


    I'm not sure its overclocking problems but I'd like to run it in a state where the tools at least agree it should work to eliminate that cause.

  7. Had a chance to play a bit more with this. I have a feeling the timing violation that you get even with the base build is actually mattering now. When I try and put all the bitmap video bits together with SocZ80 I get a lot of strangeness including things like corruption on the uart, cases where the Z80 executes code but if I swap a single fetch from video ram in the video code for a constant it doesn't etc.


    I guess it's struggling to route all the block RAMs.


    If I give it 4K of video RAM and run a text mode state machine with your font ROM and my VGA clock generators a bit of debugging all seems to be working ok. For the moment people will have to live with 128 text characters with configurable foreground/background/bright colours or inverse video. Both 80x30 and a nice retro 40x30 are supported so you can run 40x30 with white chunky writing in white on blue.


    Need to tidy a few of the other bits up some more and go through the Intel paperwork formalities to release this as an own time project but then I'll make it available for everyone to laugh at my VHDL. I know there are some definite design mistakes in the video, in particular I should have clocked the video engine at twice the pixel clock. On the other hand given it works at the pixel clock and accesses the RAMs one after another it ought to be able to do 1080i ;-) with some tweaking.


    VHDL does seem to be somewhere half way between programming and sticking your head in a blender. Its the first language I've dealt with where the result is the answer to the question you asked last time (or frequently the time before that...).



  8. Thanks - that's useful to see for things like the pipelining which I've managed to avoid so far for most of it although I think as I've got buffers on the syncs my pixels are probably one pixel clock out at the moment.


    I've attached 32K of video RAM (leaves only 2 RAM16BWERs free) which is almost enough to be ideal but not quite.


    In the end I deleted most of the original, split it into more processes and turned it into a trivial machine which executes a series of 16 2bit wide codes in a loop. The codes being

                   - Load the next byte of video RAM for the next pixel

                   - Hold the current pixel

                   - Rotate to the next pixel in the byte

                   - Spare


    Video modes supported at this point are 640/320/160 rows at 1/2/4 bpp. Depth is currently always 480 because I want to improve the driver to read scan bases from a list each scan line. That will allow for scrolling sensibly but also ensure that 640x480 text mode is useful (all the blank lines between text can point to the same scan without which it won't fit in 32K). Since that gives you x 240 modes I didn't see the point in adding a hardware scan doubler.


    Also need to work out how to do arrays of registers so I can d a 256 entry colour table, which will make it possible to do full colour mode (but with quite chunky pixels) and colour chaining mode (where the colour of a pixel is used as the top bits of the colour of the next pixel)


    That, vblank and hblank interrupts and a pixel level soft scroll register ought to keep me occupied for quite a while 8)


    But it works.. and it's currently showing a very bad retro mono picture of a Papilio Logic Wing 8)



  9. 7 segments now seem to work.


    I know what dual ported RAM is - but took me a while to find out how to declare RAMB16BWERs for it.


    I have however got VGA(ish) signals at 32MHz (should be 31.5) and a plain blue screen so progress. Once I figured out that the syncs were inverted, I wanted 32MHz not KHz and needed to generate hsyncs during vsync the monitor finally admitted I had a display.


    Now trying to plumb in some RAM. I've added 8K for testing and experimentation but 640x400 needs 32K for 1 bit mode.


    Would be interesting to see how I should have done it though!

  10. Greetings


    I'm currently starting by jumping in at the deep end playing with SocZ80. The T80 processor vhdl is well commented and readable so very informative even though I'm sticking to adding simple I/O devices to SocZ80 at the moment!

  11. I'm currently fiddling with SocZ80 a bit more, having jumped in at the deep end and failed spectacularly on the first attempts. It's now running with the logicstart board


    So far I've got the switches done (0 is reset, 1-7 are the GPIO), the LEDs now use the LogicStart LEDs, the joystick can be read and the audio output driven. No sigma dac nonsense, pure full on retro 1 bit audio. The ADC is wired to the SPI instead of an SD card but needs some code writing to use it yet.


    I also fixed the annoying habit SocZ80 had of returning a byte of ROM space for undefined I/O. Undefined banks now return 0xFF


    Next stop the 7 segment displays.


    VGA may be a bit harder 8) at least until I learn a lot more about clocks and about dual ported ram.