Outstanding work!gertk wrote:Just to get the hang of this Bare Metal stuff I ported my mbed ZX81 emulator to the Pi
No SDcard or USB keyboard yet alas..
I won't take to the coding, but you could do worse than virtual machines for this king of stuff. This solves task, process and memory. With maybe a few extra keywords (or reuse of unused ones LPRINT etc), to evaluate an expression in a foreign context. Interrupts could be multiplexed by using the foreground machine as master, and any new master may override any GPIO pin for example, on ending or view switch an old master releases any pins used by the new master (even ones the new master opened and did not close ages ago). If new contexts could be created just by using one programatically by name (or #number), then extra memory could be used by creation of a new machine context, and population of it's variables. This all makes for a co-operative task switch on display memory update, with priority given to the front most virtual machines.hermanhermitage wrote:of course resource management (task, interrupt, processes, memory) is a little tricky to do in a neutral manner. Any takers?
Not what I'm suggesting at all.jackokring wrote:I won't take to the coding, but you could do worse than virtual machines for this king of stuff.hermanhermitage wrote:of course resource management (task, interrupt, processes, memory) is a little tricky to do in a neutral manner. Any takers?
Each library needs OPEN, CLOSE, TXRX functions. TXRX accepts a command string, the contents of which are the command language of the interface. So construction of the command language is the abstraction. In fact one function call TXRX is needed, and open and close can be done on first and last use. Device selection could be part of the IO language.hermanhermitage wrote:Not what I'm suggesting at all.jackokring wrote:I won't take to the coding, but you could do worse than virtual machines for this king of stuff.hermanhermitage wrote:of course resource management (task, interrupt, processes, memory) is a little tricky to do in a neutral manner. Any takers?
Instead I'm suggesting a policy agnostic library in C and assembler for re-use in different bare metal and OS projects. The key points (1) being C and asm are widely available and require minimal hosting and it's a well trodden path, and (2) there is only so much fun in raw SD, Ethernet and USB lower level layers - its ripe for re use to allow everyone to get on with the things that do excite them, like a Scheme based OS or a vintage emulation OS etc.
The skill is in the balancing act of setting up the hooks so the same raw code can be hosted in a suitable form for drivers across a range of OS from Linux to RISC OS to Tufty's or Dex's work etc.
Suggest you post a link to your proposed solution on GitHub rather than spamming the forums - I'm sure I'm not the only one with frayed patience to these endless incoherent and Ill explained ideas.jackokring wrote:
Each library needs OPEN, CLOSE, TXRX functions. TXRX accepts a command string, the contents of which are the command language of the interface. So construction of the command language is the abstraction. In fact one function call TXRX is needed, and open and close can be done on first and last use. Device selection could be part of the IO language.
At the moment I just copied the C source of my mbed project and, sorry to say, but at the moment the mbed ZX81 emulator runs rings around the Pi in terms of speed (I manage over 4 times original ZX81 speed on the mbed @ 100 MHz, that is with heavy DMA going on to generate VGA output on the I2S bus output) Ofcourse on the Pi I have to push more data to emulate the screen. I am using 16 bpp now. On the mbed I generate the complete pixeldata from the ZX81 DisplayFile memory on each Vsync and it can keep up easily. On the Pi I have setup a simple counter variable which counts Z80 opcodes and after n opcodes it generates the display from the ZX81 DisplayFile memory. I'm not sure if the display routine is the culprit or the Z80 emulation compiled by gcc is a lot slower than when using the mbed compiler. The emulator on the Pi is doing 4 to 5 frames per second...jackokring wrote:I bet it's fast. I hope you take advantage of the multiple of memory to do a lot of pre-decoding of the Z80 bytecode. I suppose cross compiling it to ARM code in 4* the bytes could be expensive in memory? The nightmare of self modifying code with entry to the instruction stream half way through an opcode for multiple use.
Yes it still does Hey, it is a feature not a bug.. Albeit, on a 16k ZX81 you almost never see that happen..Does the display disappear as you run out of memory?
Code: Select all
ldr r0, =0x2000B214 ldr r1, =0x00010000 str r1, [r0]
Code: Select all
/* Reset interrupt via SMICS register */ ldr r0, =0x20600000 mov r1, #0 str r1, [r0]
Code: Select all
/* Address of GPU Pending 2 register */ ldr r0, =0x2000B208 /* Wait for the 48 SMI / VSync interrupt to occur */ LoopVSync$: ldr r1, [r0] tst r1, #0x00010000 beq LoopVSync$
After some testing it seems that the Vsync interrupt is occuring midscreen ?DrPinball wrote:Let me know how you get on with it!
If you've got a link to the Z80 specific (opcode decode, dispatch and evaluation C) files, I'd be happy to look at it for possible optimization.gertk wrote:I'm not sure if the display routine is the culprit or the Z80 emulation compiled by gcc is a lot slower than when using the mbed compiler. The emulator on the Pi is doing 4 to 5 frames per second...
Due to limited IO pins this might not be feasible but my first priority is to get SD card access and USB keyboard working. So far I have updated the screen display routine so speed is above standard ZX81 speed already (using 640x480 canvas in 16 bit).poglad wrote:Wow this is superb, only just noticed it here. Don't worry about the keyboard line handling - a ZX81 keyboard membrane is a tenner off eBay! Even if you get it working via a USB keyboard, you should retain the possibility of connecting a real membrane as an option!
Nope, since there is no FAST and SLOW in my emulator the lines are also not present, just a nice rocksteady HDMI (or CVBS) display BTW, loading and saving will be so fast there will be no lines visible (at least on the mbed it loads and saves in an instant: type LOAD "whatever.p", press NewLine and zap, program loaded..)Do you get the nice load/save lines on the screen? For testing, RAND USR 777 in fast mode dives straight into the SAVE routine for an extended period.
poglad wrote:Ahhhh... at the risk of being pedantic... no no no! Emulating the electron beam timings is a big part of the challenge of the ZX81. It really shouldn't be much more work than what you have already, you "just" have to determine whether a signal (including vsync, hsync) is actually coming from the "ZX81" as you're scanning down your frame buffer... and to follow the same kind of behaviour a TV would when the signal suddenly returns with a vsync at an unexpected moment. i.e., the picture rolls for a few milliseconds until the TV catches up.
Seriously, it's really worth doing for authenticity, and might actually be necessary for certain clever software that does special screen modes based on timing. The thrill of a ZX81 with rock-solid display would soon dissipate... rather like a Speccy without attribute clash hehe!
Hmm, I know that chip in SPI form: the MCP23S17, did a graphic LCD display attachment with it on the mbed, even a YouTube clip is lingering around http://www.youtube.com/watch?v=Hi2m3tru ... i2m3truUfIpoglad wrote:Goody!!! This is great stuff.
Concerning the shortage of GPIO pins for use with a membrane keyboard, I wouldn't worry much about that. As long as the keyboard is put through something like a MCP23017 chip, which is just a wiring job really, it will magically transform into an i2c device that requires only two pins. Err, so they say.
That will be the easiest part, I can add whatever I want into the memory or IO map. For ZX81 Basic it would be easiest to put it into the memory map so you can access it with Peek and PokeNow, if you can map GPIO access into the memory or port space of the ZX81, then we'll be able to write software to control the Gertboard etc.