Search
93 results for “bread80”
-
The first stage of my CPC ZERO build - a hypothetical 6502 based Amstrad CPC taking inspiration from the prototype 6502 board and the final Z80 based CPC464.
I'm using period appropriate hardware, wire wrapping the build, and solving design challenges the way they had to in the eighties.
In this zero-th part I state my design goals, choose a build method and build out the CPU and ROM.
https://bread80.com/2024/11/01/cpc-zero-part-0-intro-cpu-and-rom/
-
I've just pushed a very long overdue update to my Datapoint 2200 repository.
New stuff includes schematics for video, keyboard and keyboard logic.
I've added a fair few LEDs to the processor PCB for most of the main registers, but I need to analyse which other signals deserve to have them.
I also need to add some photos and PCB renders to the readme.
-
I've just pushed a very long overdue update to my Datapoint 2200 repository.
New stuff includes schematics for video, keyboard and keyboard logic.
I've added a fair few LEDs to the processor PCB for most of the main registers, but I need to analyse which other signals deserve to have them.
I also need to add some photos and PCB renders to the readme.
-
I've just pushed a very long overdue update to my Datapoint 2200 repository.
New stuff includes schematics for video, keyboard and keyboard logic.
I've added a fair few LEDs to the processor PCB for most of the main registers, but I need to analyse which other signals deserve to have them.
I also need to add some photos and PCB renders to the readme.
-
I've just pushed a very long overdue update to my Datapoint 2200 repository.
New stuff includes schematics for video, keyboard and keyboard logic.
I've added a fair few LEDs to the processor PCB for most of the main registers, but I need to analyse which other signals deserve to have them.
I also need to add some photos and PCB renders to the readme.
-
I've just pushed a very long overdue update to my Datapoint 2200 repository.
New stuff includes schematics for video, keyboard and keyboard logic.
I've added a fair few LEDs to the processor PCB for most of the main registers, but I need to analyse which other signals deserve to have them.
I also need to add some photos and PCB renders to the readme.
-
-
The caller has to copy the data into the correct stack location. The challenge is that the caller is not in the function's stack frame, so it's need to calculate where data must go as an offset from the current SP. And that offset will depend on how many parameters are still to be pushed on the stack.
The code here isn't actually very complex, but it's a mind freak.
Here's the function dispatch which generates IL for the copies. V is the callees variable.
-
Last up is value parameters for 'pointered types' (those which are passed via pointers rather than in registers). The function needs to be able to modify the data without affecting the original value. That means a 'hidden' copy of the data (the array) into the function's static variable space. No data need be passed in registers - the function can use the static address of the variable/data.
-
That wasn't too difficult to get working. The atomic unit of expressions is the TExprSlug, either for the result of an expression, sub-expression or function. The slug then gets assigned to a variable.
I added a field to the Slug to point to the location in the IL which loads the pointer before the call - the pointer to where to store the result data. Then updated the write-slug-to-variable code to detect this field.
The code shows nested calls with a temp var.
-
Moving on to the scenario where the function return value is a pass by reference. To do this the caller needs to pass a pointer to the data location so the function can write to it.
Currently the expression parser has no knowledge of where a function result will be assigned. I’ll probably end up checking if the result is pass by reference and, if so, find or create the target variable and pass it into the function dispatcher.
-
I'm doing the detailed work on access specifiers and parameter passing.
Today's update is CONST arguments. Variable data now has an IsConst field and there's an assertion when incrementing the 'write version' of the variable - which aids testing and helps track down code which needs updating.
Writing to a CONST variable now fails, as does passing to as a VAR or OUT argument.
-
The key switches I chose for the Datapoint 2200 keyboard required a plate so I made one up. Done as a PCB it’s not cheap but the Matt black finish works really well.
The only issue is that it slightly obstructs a couple of capacitors 🙁
I still need to source the hardware to properly mount it to the keyboard.
-
The key switches I chose for the Datapoint 2200 keyboard required a plate so I made one up. Done as a PCB it’s not cheap but the Matt black finish works really well.
The only issue is that it slightly obstructs a couple of capacitors 🙁
I still need to source the hardware to properly mount it to the keyboard.
-
The key switches I chose for the Datapoint 2200 keyboard required a plate so I made one up. Done as a PCB it’s not cheap but the Matt black finish works really well.
The only issue is that it slightly obstructs a couple of capacitors 🙁
I still need to source the hardware to properly mount it to the keyboard.
-
The key switches I chose for the Datapoint 2200 keyboard required a plate so I made one up. Done as a PCB it’s not cheap but the Matt black finish works really well.
The only issue is that it slightly obstructs a couple of capacitors 🙁
I still need to source the hardware to properly mount it to the keyboard.
-
The key switches I chose for the Datapoint 2200 keyboard required a plate so I made one up. Done as a PCB it’s not cheap but the Matt black finish works really well.
The only issue is that it slightly obstructs a couple of capacitors 🙁
I still need to source the hardware to properly mount it to the keyboard.
-
The first working test of pass-by-reference for arrays in register calling convention. Each variable has an addressing mode. The parameters use vaStaticRef - a static variable with a reference to the actual data address.
The code generator knows how to get from the addressing mode to the required data.
-
Bounds checking added to array indexing. Surprisingly easy - I just needed to add a call to the GenRangeCheck function, passing in the register, plus from- and to-types.
And a few edge case glitches solved largely around primitive selection, which was affecting the register in which the index was being passed.
-
Array support in Quiche is progressing nicely. I've added support functions Low High, Sizeof and Length, and now code to adjust for non-zero lower bounds when dereferencing an element.
Currently only for static array variables - pointer based derefencing will be the next step.
Images show the source and assembly code. I've hand added comments to the assembly. Plenty of room for optimisation here.
-
Top row numbers can be shifted and keypad numbers can't. Both share an edge detector circuit and multiplexer 'line'. Top row key short to ground whereas keypad key have an SIO (or S10) signal. The keyboard logic board uses an analogue edge detector with 74121 pulse generator.
On the Pico I'm handling this by driving the SIO line low. When a keypress is detected I drive it high. If the keypress is still detectable then it's a top row key. If not then keypad.
-
Top row numbers can be shifted and keypad numbers can't. Both share an edge detector circuit and multiplexer 'line'. Top row key short to ground whereas keypad key have an SIO (or S10) signal. The keyboard logic board uses an analogue edge detector with 74121 pulse generator.
On the Pico I'm handling this by driving the SIO line low. When a keypress is detected I drive it high. If the keypress is still detectable then it's a top row key. If not then keypad.
-
Top row numbers can be shifted and keypad numbers can't. Both share an edge detector circuit and multiplexer 'line'. Top row key short to ground whereas keypad key have an SIO (or S10) signal. The keyboard logic board uses an analogue edge detector with 74121 pulse generator.
On the Pico I'm handling this by driving the SIO line low. When a keypress is detected I drive it high. If the keypress is still detectable then it's a top row key. If not then keypad.
-
Top row numbers can be shifted and keypad numbers can't. Both share an edge detector circuit and multiplexer 'line'. Top row key short to ground whereas keypad key have an SIO (or S10) signal. The keyboard logic board uses an analogue edge detector with 74121 pulse generator.
On the Pico I'm handling this by driving the SIO line low. When a keypress is detected I drive it high. If the keypress is still detectable then it's a top row key. If not then keypad.
-
Top row numbers can be shifted and keypad numbers can't. Both share an edge detector circuit and multiplexer 'line'. Top row key short to ground whereas keypad key have an SIO (or S10) signal. The keyboard logic board uses an analogue edge detector with 74121 pulse generator.
On the Pico I'm handling this by driving the SIO line low. When a keypress is detected I drive it high. If the keypress is still detectable then it's a top row key. If not then keypad.
-
Moving on to the shift and shift lock keys. If a top row number is pressed the logic board can just flip a single bit to convert to the relevant symbol. For the symbols in the same ASCII block (&30 to $3f) : and ; can be treated the same, but for < to ? the bit needs to be flipped in shift is not active. There are similar issues for symbols after Z and z.
1/n
-
...except that I only just noticed the signal names for the lower letters and numbers are swapped. Or maybe the names just have their bit ordering reversed?
And after some tweaking of the software timings for the scanner I have every multiplexed key working correctly.
The secret to doing this in software seems to be to continuously scan, then sleep briefly once a keypress have been registered. The hardware debounce is too quick for the usual 50/60Hz scan.
-
I wired up a connector so I can use a Pico + breadboard to test the keyboard. At the moment I only have the wires driving and reading the multiplexers connected.
-
…and assembly is complete. The original looks like it would have been deliciously clicky so I’ve chosen suitable keyswitches. However they’re only 3-pin so really need a plate to hold them properly in place.
The keycaps are standard modern layout so don’t have the correct legends. But they do look good enough to eat.
I still need to source correct bulbs for the lamp holders next to the ‘system’ keys on the right hand side.
-
Resistors, ceramics and sockets done. I think that’s enough for today. I need to dig out the big camera to do this shot justice.
And yes, I did make sure every cap faces the same way, and rework to ensure they’re immaculately aligned. This board deserves nothing less.