Great work! Just a FYI, you can remove the scratches from the red acrylic panel by using a car polish designed for restoring the plastic lens on car headlights
One thing I've learned about multiplexing LEDs is to be extremely careful that the wrong LED is never energised even for a microsecond, as the capacitance in some LEDs (especially surface mount LEDs) can make them glow noticeably even if they are energised for only a few µs per second. So code should do: turn on specific LED lines (eg 1&5&8), turn on common line, pause for duration (which can be used to set intensity, sort of), turn off common line, turn off specific LED lines, then go to next common line. If you simplify the code so it is something like: turn on specific LED line, turn on common line, pause, turn on new LED lines, switch common line, even though those last two happen in µs, you can get ghosting.
@PeterNLewis, yeah, I did gloss over this detail in my explanation. If you look at my code, you will see am doing this (turning off the common line before adjusting anything). Then there are other issues with LED ghosting in a multiplexed array, like the time it takes for the switching transistors to turn on and off, but that's at another level of detail.
did you notice that the 4 pnp's seem to have their c-e's swapped, so you drive vcc not from emitter to collector of the pnp, but instead in reverse? or is this on purpose...?
Huh .. yeah, I will need to double check that. I do know this is right for the speaker, as that is in an emitter follower arrangement (note the collector connects to ground there), but I think you are right for the various LED banks, now that you point it out, the schematic doesn't make sense. Thanks for pointing it out, i will fix the schematic (after double checking the hardware) in the github repository.
Yeah, but I would need to implement some sort of scrolling for the hex display as a 16 bit number needs 4 hexadecimal digits to display it (each hexadecimal digit is 4 bits).
@@MichaelKamprath You can display the results in binary on your "16-bit" LED matrix. One nibble per row. The suggestion doesn't make it more user friendly, but hex isn't user friendly either. It's just easier to manipulate. You could effectively show 24 bit integers, if you didn't mind part of it binary and part of it in hex, but I'm not sure if you'd have enough ram to implement something like that.
This is a very old computer, but have you checked if it is Y2K compliant? This is very important, if not people show up on leap-years day when they would have ben free, or people bring back their rental video to late.
could have scrolled the 16 bit value on the screen >xx xx >xx D0 >02 D0 >D0 xx >xx xx but that would be a lot more code in that clearly difficult F8 asm
Great work! Just a FYI, you can remove the scratches from the red acrylic panel by using a car polish designed for restoring the plastic lens on car headlights
Thanks for this tip! I will try it out.
Michael, this makes me very happy.
Thanks again for the extra TEAMMATE!
One thing I've learned about multiplexing LEDs is to be extremely careful that the wrong LED is never energised even for a microsecond, as the capacitance in some LEDs (especially surface mount LEDs) can make them glow noticeably even if they are energised for only a few µs per second. So code should do: turn on specific LED lines (eg 1&5&8), turn on common line, pause for duration (which can be used to set intensity, sort of), turn off common line, turn off specific LED lines, then go to next common line. If you simplify the code so it is something like: turn on specific LED line, turn on common line, pause, turn on new LED lines, switch common line, even though those last two happen in µs, you can get ghosting.
@PeterNLewis, yeah, I did gloss over this detail in my explanation. If you look at my code, you will see am doing this (turning off the common line before adjusting anything). Then there are other issues with LED ghosting in a multiplexed array, like the time it takes for the switching transistors to turn on and off, but that's at another level of detail.
did you notice that the 4 pnp's seem to have their c-e's swapped, so you drive vcc not from emitter to collector of the pnp, but instead in reverse? or is this on purpose...?
Huh .. yeah, I will need to double check that. I do know this is right for the speaker, as that is in an emitter follower arrangement (note the collector connects to ground there), but I think you are right for the various LED banks, now that you point it out, the schematic doesn't make sense. Thanks for pointing it out, i will fix the schematic (after double checking the hardware) in the github repository.
You could always display the input in the hex display and output to the matrix which is effectively 16 bit.
Yeah, but I would need to implement some sort of scrolling for the hex display as a 16 bit number needs 4 hexadecimal digits to display it (each hexadecimal digit is 4 bits).
@@MichaelKamprath You can display the results in binary on your "16-bit" LED matrix. One nibble per row.
The suggestion doesn't make it more user friendly, but hex isn't user friendly either. It's just easier to manipulate.
You could effectively show 24 bit integers, if you didn't mind part of it binary and part of it in hex, but I'm not sure if you'd have enough ram to implement something like that.
@@mikechappell4156 oh I totally misunderstood you. Yeah, you're right.
this was nice, I like it, nice job
Thanks!
This is a very old computer, but have you checked if it is Y2K compliant? This is very important, if not people show up on leap-years day when they would have ben free, or people bring back their rental video to late.
I don't think it is Y2K compliant! I'll look into fixing that ;-)
could have scrolled the 16 bit value on the screen
>xx xx
>xx D0
>02 D0
>D0 xx
>xx xx
but that would be a lot more code in that clearly difficult F8 asm
Yeah, I thought about that, but plainly, it would have required more effort than I wanted to do and the user experience wouldn’t be great.