6502.org

Brilliant! And well-documented too. The result is a lovely nostalgic sort of Acorn-Atom with Arduino aspirations
Well done and thanks Gordon.

Thanks.

Curiously, in the early 80s I designed a set of boards with a 6502, RIOT, 2K EPROM and 'glue' which then talked to a 2nd board with "industrial" IO (opto isolators, relays, etc.) which was used in the control of a simulated factory automation project I was working on at uni... So Arduino of it's time, as it were. If I had this board then, it would have been a lot easier as it could all have been written in Basic rather than assembler...

(Of-course I'd still have had to write the Basic in assembler - can't win!)

Cheers,

Gordon

Spoiler alert : old guy rambling...
I have, for a very long time, been aiming at a sort-of WBCTM like Garth's - with proper IO and programmed in a 'respectable' language.
My Acorn Atom had a home-made board plugged into the back of it and used the VIA to pilot a few inputs and outputs (and the printer, of course).
I used it for various experiments whenever I wanted digital IO. Then career got in the way, my Atom got drowned... and I discovered PICs and later the AVR chips and Arduino. Each time I found myself re-building a piece of temporary test kit with a micrcontroller inside it I would inwardly swear at myself for not yet having the WBC...

The journey is one of learning and experimenting and getting side-tracked into all sorts of interesting corners, but the target is still there.

I've adopted the 'respectable' language : PLASMA, it is well structured and easy to write, and has some neat features. I had *almost* finished what was called WBC3 and which had on-board SPI and I2C but was lacking in a decent monitor.
Then I tried the RP6502 'Picocomputer' and I liked what it could do, especially with PLASMA on board. I wrote a self_hosted assembler for it and it got me thinking about the 65816 and the extra possibilities that it could provide. The author of the RP6502 was most unhelpful (sic) when I asked for pointers to migrate the 'picocomputer' to the 65816. He even banned me from their forum! I was quite chuffed - never been banned from anything, me. So I've reverse-learned the R Pi Pico2 environment (the source code has virtually no documentation) and have a Frankenstein-like contraption with two logic analyzers plugged-into it. Almost there... The idea is that, as the RP2350B is already providing the file system, monitor, etc. it could also provide the SPI, I2C and other services - leaving a HUGE memory-map free on the '816. The 'picocomputer' sits on a 100x150 board, the '816 version could be around the same size - perhaps a bit bigger for all the I/O connectors.
So - don't hold your breath - but there should soon be another new contraption to show-off !
Ramble over!
(EDIT: a few typos)

You mean; another old guy rambling

Anyway, as a diversion, meet my '816 board: https://projects.drogon.net/ruby816-hardware/ that's Rev 1, not sure I have a decent photo of rev2.. So; 512K RAM, 16Mhz, a VIA for IO, plans for a backplane for more IO and self-hosting in a decent high level language (ok, BCPL)...

I sort of ran out of enthusiasm for it though. I can edit, compile and run BCPL programs on it and the underlying memory system is transparent to those pesky 64K banks.

The 6502 boards I mentioned a couple of posts back were front-ended by a BBC Micro and these (many) were connected together with Econet. Not bad for 1983.

-Gordon

Thanks for the detailed update Gordon - really liking where you've got to with Project-28.

Here's an intersting bug I've just found - in my GIBL/TinyBasic interpreter..

When editing/writing programs more than a few lines long, I use an external editor, then I simply squirt the text file down the serial line. This works remarkably well and at the new high-speed 38400 baud it's faster. (I have a 1ms inter-character delay and a 80mS inter-line delay and the program I use allows that to be configured - minicom +ascii-xfr). Since it's a half-duplex link, I turn output off by typing Ctrl-O before I start the send and turn it back on again (another Ctrl-O) when done.

This works well and no need to muck about with xmodem, et al. Maybe one day.

To save code space I put REM statements on a line without a line number. Seems odd, but then they don't take up any space in the precious 3¾ KB of RAM.

An example:
and so on.

When the interpreter parses a command, e.g. LET, IF, etc. it calls the handler via JSR, expecting a return via RTS. This is well and good, except for one little thing; In immediate mode, the REM statement (and a few others, e.g. END) returns via JMP to the start of the interpreter.

Which gradually increases the stack usage.

So-far I've gotten away with it - mostly as I've had a lot of stack to play with, but now add in that vectored jump code at $180 and it starts to get tight - right up to the point it overwrites the code to jump into the monitor ROM at which point it crashes or reboots.

There's a lesson to learn there, somewhere, but right now while I've fixed the issue I've yet to learn just what that lesson might be...

Cheers,

-Gordon