|
Re: Strange behavior of #8 button
Kerem Kapkin wrote: > Here is the recommended setup for standalone testing of the front panel... > J2 Pin 9 [/out] connected to 3 components. 0.1uF cap other end ground, > momentary switch other end ground, > 100K resistor other end Vcc(5V). ? Correct. This provides a debounced pushbutton to clock counter U2A. ? > J2 Pin 24 -CLOCK- high (Vcc) or low (Ground) ? Either is fine; you just don't want to leave a CMOS input floating. ? > P1 pin 1 ground to (-) power supply ? Or J2 pin 10 also works. ? > J2 Pin 19 Vcc to +5V power supply ? With this setup, you can step counter U2A through its states 0-7. Each state is output on J2 pins 11, 12, and 13. Each state should set the corresponding output of U3 low so you can test each button. ? I think I see the problem with the "8" key! When U3 output C0 is low, IN4 (J2 pin 15) should be high. But transistor Q3 is also connected to C0. It is a "pre-biased" FJN3305, which has internal 10k and 4.7k resistors between its base and emitter. Its emitter ties to C0, and its base to R1D, a 1.5K to ground.These three resistors (10K + 4.7K + 1.5K = 16.2K) are pulling C0 low despite 18K R4A trying to pull it high! Thus the "halfway between" logic level, on IN4. ? I'm busy preparing for VCF-East right now, but will confirm this when I return. In the meantime, I'll bet putting a lower value resistor (like 1.5K) in parallel between R4A pins 1-2 will fix the problem. Lee -- Excellence does not require perfection. -- Henry James But it *does* require attention to detail! -- Lee Hart -- Lee A. Hart |
|
Re: Strange behavior of #8 button
Here is the recommended setup for standalone testing of the front panel, just to make sure it is the correct start. -J2 Pin 9 [/out] is connected to 3 components. 0.1uF cap other end ground, momentary switch other end ground, 100K resistor other end Vcc(5V). Original recommendation was to use J2 Pin 8, however (b)TTL option that pin is not connected to anything but P1 TX 5. -J2 Pin 24 -CLOCK- high (Vcc) or low (Ground) -P1 1 ground to (-) power supply -J2 P19 Vcc to +5V power supply On Fri, Mar 28, 2025 at 5:01?PM Lee Hart via <leeahart=[email protected]> wrote:
|
|
Re: Strange behavior of #8 button
> I cannot get S8 work no matter what. While running FFF1 sequence it is using 92mA current at 5V supply. ? OK, that's correct. You have enough 5v power. ? > While testing with the logic probe, 74LS145 inputs to A(15), B(14) and C(13) are fine but D(12) is always LOW. ? That's also correct. 74LS145 input D (pin 12) is always low when the interrupt handler is working. The inputs to it count from 0-7 and repeat. If the Z80 interrupt handler fails to respond to the keyboard/display interrupt, then input D (pin 12) goes high to disable the LED display and keypad. ? As I described earlier, you can test the Front Panel by itself, without the CPU board. You should be able to set the A B C inputs of the 74LS145 (with the 74HC393 counter) to each of the 8 states, then operate each keypad key in turn, and see the IN bits identify which key you pressed. ? Lee ? I am using the (b) TTL configuration both on the Z80 card as well as the Front panel. -- Excellence does not require perfection. -- Henry James But it *does* require attention to detail! -- Lee Hart -- Lee A. Hart |
|
Re: Strange behavior of #8 button
I cannot get S8 work no matter what. While running FFF1 sequence it is using 92mA current at 5V supply.? While testing with the logic probe, 74LS145 inputs to A(15), B(14) and C(13) are fine but D(12) is always LOW. I am using the (b) TTL configuration both on the Z80 card as well as the Front panel. On Fri, Mar 28, 2025 at 4:04?PM Lee Hart via <leeahart=[email protected]> wrote: Ah; that may be a hint. The Z80MC runs *cold". Everything is CMOS, nothing gets hot. |
|
Re: Strange behavior of #8 button
Ah; that may be a hint. The Z80MC runs *cold". Everything is CMOS, nothing gets hot.
What are you using for a power supply? Could its voltage be insufficient? USB supplies are often weak, and the cables so thin that they have lots of voltage drop. I haven't seen this problem with the Z80MC (which draws less than 100mA), but it often happens with the Altaid 8800 (which draws close to 500mA). Lee -- Excellence does not require perfection. -- Henry James But it *does* require attention to detail! -- Lee Hart -- Lee A. Hart |
|
Re: Micro BASIC Manual
Hi Lee,? I will try your suggestion. I have the front panel on my breadboard now with your suggestions for testing. Have a safe trip, when you are back we can reconnect for troubleshooting. Thanks, Kerem On Fri, Mar 28, 2025 at 9:46?AM Lee Hart via <leeahart=[email protected]> wrote: You're the second person to mention problems with the "8" key. I haven't seen it myself, and from the schematic, can't imagine what could be wrong that only affects the "8" and not the other keys in the same row. |
|
Re: Micro BASIC Manual
You're the second person to mention problems with the "8" key. I haven't seen it myself, and from the schematic, can't imagine what could be wrong that only affects the "8" and not the other keys in the same row.
toggle quoted message
Show quoted text
The only thing that's changed recently is that the 15Kx4 SIP was changed to 18Kx4 (because the 15K was out of stock). It works the same on my Z80MC, but maybe some 74LS145's have excessive off-state leakage that 18k won't pull up? An easy test would be to try adding a resistor in parallel with the 18K (like 22K) to see if that helps? Lee -- Excellence does not require perfection. -- Henry James But it *does* require attention to detail! -- Lee Hart -- Lee A. Hart -----Original Message-----
From: <[email protected]> Sent: Mar 23, 2025 8:11 PM To: <[email protected]> Subject: Re: [Z80MC] Micro BASIC Manual It's funny you mention a problem with the #8 button. I have a similar problem with mine. Instead of getting 8, I get 9. Spent a bunch of hours troubleshooting. Never figured it out. Sometimes it will produce an 8. If I do E 2888, I get 2899. If I do E 7888, I get 7899. And so on. Maybe we should start a new thread... Mitch |
|
Re: using SDCC and stdio to Z80MC w/ CP/M 2.2....
Thanks for looking into it and sharing back! ?Your experience mirrors mine; I find the SDCC code generation to be a bit fluffy. SDCC is a labor of love of its authors, so I suspect that advancements in optimisations are catch-as-catch-come.
?
My reflection on this mini-project is that SDCC can be a project accelerator if you want to use modern C authoring on a desktop dev env and are not picky about code size. If you've got the flash/ram, might as well use it. My acid test was compiling an HP15C emulator within this toolchain. This resulted in a program that fit in the 32 KiB banked region and there was plenty of RAM for variables in the non-banked region. Could it be smaller? Doubles. Could it be faster? Surely. Did it take months to implement? No, because I already had the code on-hand, so I just had to concoct build scripts and implement main() to start the emulator.
?
(Incidentally I did not complete this PoC implementation because I realized much to my chagrin that calculators presume the presence of a button matrix, so... whoops! I did implement the screen rendering of the keyboard and LCD using VT100 codes. This was slow even at 115kbps. The stdio fprintf() layer was about half as fast as CP/M BIOS calls, but really still too slow even then to be pretty to look at. Since this was just a PoC for code size and execution speed, I didn't bother investing in completing key mapping, or thinking laterally, making a parser for a CLI version.)
?
I chasing other wild geese just now, though I still might come back to this as even just now a buddy is wanting to re-purpose some vintage z80-based spectroscope with alternative firmware. (Indeed, the genesis of this activity is because of some folks wanting to reverse-engineer an esoteric language CAI machine called the 'Cefucom'. I could glean a lot from disassembling the rom dump but eventually one has to buzz out the wires to know what PIO-A-bit-7 is electrically connected to, and whether port 20h selects U24 or U25. My suggestion was a custom firmware that tweaks the lines in a predictable way such that you can observe the chip select logic with a multimeter rather than reverse engineering all the intermediary SSI decode. So it was handy to be able to crank that out quickly irrespective of generated code quality.)
?
Thanks so much, Allison, for your insights and also your tales from the trenches of how things were. And are they materially different now? Or just more and faster? Well, I guess quantum computing seems different, or is that just the re-imagining of analog computers?
?
73, AG5TH, dave
|
Lee Hart
Kerem Kapkin
dave