Search
263 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/
-
#CPC464 #keyboard revision 2. Test fitting a few keys. The key change was to update the keybed position to get it better centred. And it’s now looking bang on.
(Keys are upside down because they’re pulled straight from the rev 1, and without sockets soldered I’m mounting them in the solder holes for accuracy. (Although I’ve just realised they’re fully located by the mounting lugs :shrug:))
-
Polishing off the second revision of the #Amstrad #CPC464 #MechanicalKeyboard
* Key bed repositioned by a few fractions of a millimetre.
* Diode footprint tweaked for easier hand soldering.
* Moved a couple of diodes which were uncomfortably close the connectors.
* Patched up all the traces affected by the above.I still have a couple of minor items on the todo list but this is very close to being ready for the fab.
-
What's the main challenge in assembling old code on a modern(ish) assembler? The old assemblers only consider the first few letters of a mnemonic significant. The 8008 has an INC opcode. My assembler has an INCLUDE directive.
(The old code doesn't use INCLUDE, but I need to import symbols from other files. The easy way is to write public symbols to a file in suitable format for an INCLUDE).
-
I'm debugging the ROM emulation on the Firestarter. It looks as if the code to monitor ROM enable and ROM selection is working but the host crashes once it starts accessing the ROM.
The first access of the ROM is when BASIC calls KL_INIT_BACK to initialise background ROMs.
The first read is the LD A,(&C000). A few cycles later the ROM's init routine at &C006 will be called.
-
A nice end to Sunday morning with a quick Delphi utility to convert a ROM binary to C source code.
-
Time to try some ROM emulation. The first step is to sniff the ROM enable/disable states and the currently selected upper ROM.
The code for this is, again, simple. It tests the I/O address for the ROM select IO port, and also the gate array IO port. If it's the gate array it tests the register select bits of the data and extracts the two ROM disable bits.
-
It's also very easy to change the font size with #Firemonkey. Here's the source code displayed using 1 point text - the smallest available.
It would be very easy to use this to add one of those fancy overview windows that posh code editors have.
-
I have a couple of projects which could benefit from some kind of owner draw text control. I've never done that before using #Delphi #Firemonkey.
It's actually really easy so I've been writing a simple text editor. About three days work of to get all the main cursor movements, editing, selections and scroll bars is impressive.
A bit more work with cut/paste and mouse dragging and this will be ready to use.
-
And I only just found this. I didn’t realise the Flan name actually made it into production.
This means it’s a revision 4 board, from the first production run. The run with bugs in the video chip and ROM.
-
The Enterprise keyboard layout is coming along nicely. The photos show a printout of the design under the matrix.
I had to redo the horizontal positioning when I realised they used the same size matrix for both dimensions and the keys are 19mm x 19mm. The error was only 1mm across the width of the board but that’s plenty enough to cause problems.
The function keys and joystick are the only things which aren’t on the matrix.
-
I want to see if I can make my #Enterprise64 keyboard a bit less ‘squidgy’. I’ve bought a selection of the thinnest tactile switches I can find to experiment with. The switches here run from 0.8mm to 2.5mm.
-
Old school DRAMs have a lot of timing requirements. I’ve been validating output from the #CPCZERO sequencer prototype against them - and everything checks out 🙂
Comments in my notes are where the timings depend on other components, such as the multiplexers.
-
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 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.
-
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.
-
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.