First off, hello, long time no see, university happened, a ram chip exploded, etc etc etc. But I have new parts on the way and a whole lot of spare time - and a Raspberry Pi sat on my desk doing nothing.

As mentioned in the main Wren Prototype post, I currently have the machine set up with an AVR microcontroller driving the clock and logging the data bus, which works but isn't ideal. The Pi, however, is much faster and has orders of magnitude more memory, and there's already a Forth for it (pijFORTHos). It doesn't have quite as many usable GPIO pins on the 26 pin header - 13 compared to 18 on the AVR - but that's still more than enough. If necessary I can solder on the P5 header for another 4 pins.

Software wise, Linux is out of the question. It should be obvious why. Someone has written a Pi logic analyser on Linux before, but half of it is a kernel module. So I thought, why not cut out the middleman, write it in assembly and maybe some C, and operate it from Forth?

My first step is some general housekeeping for pijFORTHos. Fixing up the input subroutines, adding either XMODEM or SD card access so I can actually get at the logs once they're generated, that kinda thing. Maybe I'll get completely sidetracked and end up bringing pijFORTHos up to speed with my own version of Jonesforth. Only time will tell.

As an aside, I wasn't quite sure where to put this post, as it straddles a few categories at once - so I hope general is fine.

_________________
probably the youngest person on this forum

Speed isn't everything.

Lets start with the "it should be obvious why" part first... Linux is multi-tasking sure, but that's not the issue you'll get - and you'll get this issue if you bare-metal it (or run something not Linux like the Forth you mention, or RISC-OS or my own baremetal thing) and that's simply that the Pi isn't a microcontroller - it has dynamic RAM that gets periodically refreshed as well as having a video device that periodically also steals some memory bandwidth - in essence fine-grained, "hard" real time stuff is somewhat tricky.

Another issue is voltage - which won't be an issue if you run the system at 3.3v which the Pi likes but if not, then it's level-shifter time.

And just what sort of sampling period are you thinking of?

A good project to study might be he PiTubeDirect project - this is to make a Pi emulate a 2nd processor to the BBC Micro - which means connect it to the Beebs 2Mhz bus, (via a level shifter), sampling the 2Mhz clock, reading and providing data at the right time for a 2Mhz 6502.

It was touch and go to get the code on the Pi to accurately sample the 2Mhz clock in the beginning before they moved to writing code on the GPU to do the sampling.

Another thing - the GPIO is effectively run at a different clock-speed to the CPU - it's 19.2Mhz (IIRC). Think of a slow peripheral in the 6502 world that needs clock-stretching to work...

I think this might make a good project, but please do more reading about the Pi - it might have a nice fast clock speed, but latency and jitter caused by the DRAM) may well thwart you for this sort of thing.

-Gordon

_________________
--
Gordon Henderson.
See my Ruby 6502 and 65816 SBC projects here: https://projects.drogon.net/ruby/

For the moment I'll probably be having the Pi drive the 6502's clock, which solves the timing issues.

The main thing to keep in mind is that my sole motivation for this is boredom. The more problems I have, the better. Even if all I get out at the end is a better Forth for the Pi and the knowledge that what I'm trying to do doesn't work, I'll be happy.

_________________
probably the youngest person on this forum

Yes, driving the clock from the Pi should work out - I suppose then that you just want an adequate average clock rate, to make your machine usable. And I think there's a fair chance of that.

Sure - then you can "hand-crank" the 6502 at whatever speed you like - ought to get a good few Mhz if careful.

Also, then the Pi can emulate RAM and ROM if desired.

One thing to check is the number of GPIOs you need - a 40-pin Pi has at most 27 usable pin if you use the ones marked for special purposes (e.g. I2C, SPI, serial, etc.) You need 16+8 = 24 just for the address and data bus, one for the clock, you'll likely need one for Reset too but with care you might be fine.

-Gordon

_________________
--
Gordon Henderson.
See my Ruby 6502 and 65816 SBC projects here: https://projects.drogon.net/ruby/

Unfortunately I only have a Pi 1 model B with the 26 pin header, which reduces me to 15 pins, two of which are for the UART, which I kinda need. However, I should be fine with just data bus and control line logging. I'm already well into yak shaving with Forth so don't expect me to be analysing any logic any time soon.

_________________
probably the youngest person on this forum