ASM has hit just about the right level of pain - what next?

[paulca]

There are so many ways to move data into it that I have considered.  From the PIO with an USB MCU enslaved to grabbing the datasheet for a period Floopy disk and making an STM32 be one of them.

There is a practical driver though.

I am getting tired of pulling the ROM chip.  I need to stop flitting around trying this and that and pick one, make it work.  Make it so that I can build and upload an application from an IDE.

The UART wins.  Justification:
I have completed, working, on PCB hardware that does 2 channels of UART and a 5V fine USB FTDI quad UART free ports.

Because I have 2 channels and my primary interface is itself UART.  The data channel, when being used can go onto channel 2.  It can therefore be raw binary as I do not need to see it, have it echo or anything.  This prevents the current fiasco of disconnecting "screen" so I can connect the loader and faffing around.

With a simple way to say:

make all upload

I can use that to write the "Flash programmer" Z80 side.

The worst that happens is I corrupt the ROM and have to take it out anyway.

[paulca]

Code: [Select]

Z80 MCU3232 V1
Paul Campbell 2025
>LOAD 9000 10
ERROR
>LOAD 9000 014E
Loading... 0x9000 0x014E
ok
Complete...
Press ENTER to continue...
Hello World!
Z80 MCU3232 V1
Paul Campbell 2025
>RUN 9000
Press ENTER to continue...
Hello World!
Z80 MCU3232 V1
Paul Campbell 2025
>

Works a charm.  The user app deliberately jumps back to the ROM entry.

Also:

Code: [Select]

paul@linux-dev-vm:/mnt/homes/paul/devel/Z80/z80_asm$ python3 uart_bin_loader.py upload.bin 9000
File opened ok

Serial opened ok

Wrote 334 bytes in 0.35 seconds = 0.97 kBytes per second.

Not that slow either.

Just needs to be made a bit more resilient.  Nice things like timeouts or error handling.

The python loader is now redudnant.  The Z80 is keeping up with raw 9600 baud.  So this now works too:

cat upload.bin > /dev/ttyUSB1

EDIT:
The python loader is BACK!

LOAD HHHH HHHH

Is tedious.

Why can't I just do LOAD

If you don't provide an address it will go to 0x8000 and if you do it will go where you ask.

The loader, can send a header and a length and maybe a checksum if I get that fancy.

This helps with the other issue... if you end up with something in a buffer after a failed load it's a bugger to get it to "realign" again.  If the loader can be trusted to send a header, the CPU side can spin through garbage till it hits the header and then read and validate the length before proceeding.  This may require a sync point.
> <garbage dont care>LOADER_HEADER<2 byte LENGTH>
< Some appropriate response for "ok or piss off"
> <payload bytes full rate>

[paulca]

I got the protocol implemented.  Pretty much as described, but no need for an "ok".  It's fast enough to process the header/length/payload is one shot.

I'm not posting code, it's already 250 lines.  It's all muddled up in the same file as the command-line loop.  The next task here is to refactor that out of the "test" scripts context and put what I want to keep into the ROM space.  Both the CLI and the loader.

Also made the start on a "ROM/MON" thing, out of necessity.  For a while the application was uploading and immediately locking the board.  So I could reboot it and go and look at what was in the memory.

When you are already standing on top of "Drivers" and "Str_Utils" with a working TextUI, writing a memory monitor is not that difficult.  Though it does feel good to reep the rewards of pushing everything "Up" into ROM and building on it.

The "tying together" point though.  The ROM/Mon was the first application written that didn't involving pulling a ROM chip out.  It was also the first example of multi-programming, as I could load, run several programmes without rebooting.

[brucehoult]

The python loader is now redudnant.  The Z80 is keeping up with raw 9600 baud.  So this now works too:

I completely don't understand why this would be difficult on a 1.8 MHz Z80.  187.5 clock cycles per BIT. That's easy with bit-banging a GPIO. With a UART to gather 10 bits into a byte? 1875 clock cycles per byte.

It *should* be able to handle 57600 or maybe even 115200 if, as you said before, you're not doing anything else at the same time, just decoding hex and shovelling it into RAM.

[paulca]

I tried 115200.

115200 works for console, overruns for data, at least once and that's all it takes.
57600 worked for both with an undetected byte error problem, spotted by eye.
I pondered CRC/Chksum, but tried 28800
28800 Didn't work.
14400 Didn't work.
57600 Didn't work again.
Nothing, but 9600 worked.

Note, that 57600 did work, but then didn't.  When the only value I was changing was the timer "Time constant". This tells me there is something else at play.

When "not working", the 'ART' frame was suspect, the scope was having trouble decoding it the frame size seemed to be varying.  It's either miss reading or miss writing frames or both.  The CTC baud clock looked perfect.  At 14400 it was check to be 14.39998kHz with barely a jitter in the last digit.  Strong 1 master clock pulse at 4.2V.

"screen" produced random garbage from the echo back as well as the "sent from Z80".. 

I think the DART has an '87 date code and the CTC an '86.  They are both NMOS.

I'll try again, after work, but I expect the same behaviour... sort of works, but gives up the ghost and needs to cool back down again.  Although maybe I shouldn't whip crack 40 year old chips and expect magic that isn't smoke formed.

The pair, DART and CTC, IDLE about 20mA each.  Running at 9600 that doubles.  I didn't check what they pull with dual channel 115200, but I expect that might be the problem.

[brucehoult]

The pair, DART and CTC, IDLE about 20mA each.  Running at 9600 that doubles.  I didn't check what they pull with dual channel 115200, but I expect that might be the problem.

Yes, the uart chip not being able to handle the speed or overheating is likely to be the problem. The Z80 not being able to process the data quickly enough is not -- assuming it is efficiently programmed.

[Analog Kid]

So, are you having fun yet?

[tggzzz]

Strong 1 master clock pulse at 4.2V.

Datasheet https://datasheet4u.com/datasheet/Zilog/Z8470-656613 indicates clock should be >Vcc-0.6, i.e. >4.4V.

That is sufficient to account for flaky operation.

It also indicates Icc 100mA max, so your 40mA(?) would be well within spec.

[paulca]

Strong 1 master clock pulse at 4.2V.

Datasheet https://datasheet4u.com/datasheet/Zilog/Z8470-656613 indicates clock should be >Vcc-0.6, i.e. >4.4V.

That is sufficient to account for flaky operation.

It also indicates Icc 100mA max, so your 40mA(?) would be well within spec.

The CTC VOH is 2.4V and 1.8mA. 

The DART output VoH is 2.4V @ 2mA.

So I don't know where in that day and age is't getting >4.4V, it's not from it's own family.

I set it back to 9600 and went on with things rather than "Min/Max" which was never the intent.  It's not exactly 100% reliable even at 9600.

I did have to fix an issue.  While simple things like OVRRUN the DART clears the error as soon as you read the data, other errors upset it more "sticky" and you have to go and reset it by setting 3 different bits.  So I added that which at least meant I didn't need to reset the board every 10th upload.

I also have custom made UART leads, which are not looking the best.   Those crimp strips were never made for humans.  Some leads I have made are still working fine.  Others come apart or never fit the JST header properly.  At the moment I need to lift the IO board to get to the ROM chip ZIP socket underneath.  This means the UART leads are constantly being disturbed and those homemade leads do not like it.   "Why you not working now?", "Oh, the lead fell out."

I got the bare minimum "monitor" app written.  Just simple things like "read some memory", "write a memory location".  Print 1kb of strings from address.  Write to raw IO port (yes, you can reconfigure the DART running your console and ... end it), Read from a raw IO port.  The IO read/writes are for the FPGA integration I have upcoming.  Should make it a lot easier to test that without having to write ASM and upload every change.

Maybe the weekend I want to remove the last need to use the ZIF socket and write a flash rom programmer.  I already have the protocol "for ease" worked out.  I use the existing UART loader to upload the sector to be written to RAM.  Then load the flash programmer into RAM as well and run it.  If done right the Z80 can be kept out of ROM addresses long enough to allow the flash to erase and then write the sector.  Without relocating my ROM routines (no thanks), I will be mostly "bare metal again!"

I might do something fun instead, I haven't played with sending terminal control characters yet and doing goofy stuff in the console.

[tggzzz]

Strong 1 master clock pulse at 4.2V.

Datasheet https://datasheet4u.com/datasheet/Zilog/Z8470-656613 indicates clock should be >Vcc-0.6, i.e. >4.4V.

That is sufficient to account for flaky operation.

It also indicates Icc 100mA max, so your 40mA(?) would be well within spec.

The CTC VOH is 2.4V and 1.8mA. 

The DART output VoH is 2.4V @ 2mA.

So I don't know where in that day and age is't getting >4.4V, it's not from it's own family.

Completely irrelevant.

The relevant spec is V_IHC. Note the bold characters.

[paulca]

The pair, DART and CTC, IDLE about 20mA each.  Running at 9600 that doubles.  I didn't check what they pull with dual channel 115200, but I expect that might be the problem.

Yes, the uart chip not being able to handle the speed or overheating is likely to be the problem. The Z80 not being able to process the data quickly enough is not -- assuming it is efficiently programmed.

I think it's old and past it's best.  So if it were a new 16550A or similar I might call it broken.  I just think it has character.  There is also the point the board is 100% custom design, so I could have screwed up somewhere dramatically simply and ruin it.  Like putting 100R series resistors on the UART Tx and Rx which didn't seem to do much except for pick up noise.  Then again that's unfair, I'm comparing what the scope looks like on a board "pin" versus what it looks like on a UART flying lead.  Obviously the later is an antenna and highly likely to be noisier.   The noise is proportionally small to the signal which is important.  There is nothing even approaching the TTL triggers.

The hour or so I spent with the scope while I had it faster and failing the frames where mangled.  It looks like it tried to draw the "START bit down and gave up.  There is about 0.5V dip where the start bit should be, then a 0.5V overshoot, then it goes back to clocking bits, having completely missed the start bit.

So while I was spamming the "space" key, the scope was seeing 0xF0 or something weird or under sized frame.  Then it would send frames with a start bit that were about 1 bit too long.  OVERLEN

It does suggest an edge triggering problem, but not one way, it seems to miss pulses, but double as well.

I don't mind if it says,"Loading failed, retry..." once in a while, but I do need the checksum.  I have seen garbled ASCII in uploads and while that is amusing a bit flip in ASM code probably won't be.

[paulca]

Strong 1 master clock pulse at 4.2V.

Datasheet https://datasheet4u.com/datasheet/Zilog/Z8470-656613 indicates clock should be >Vcc-0.6, i.e. >4.4V.

That is sufficient to account for flaky operation.

It also indicates Icc 100mA max, so your 40mA(?) would be well within spec.

The CTC VOH is 2.4V and 1.8mA. 

The DART output VoH is 2.4V @ 2mA.

So I don't know where in that day and age is't getting >4.4V, it's not from it's own family.

Completely irrelevant.

The relevant spec is V_IHC. Note the bold characters.

I don't think that means the baud trigger clock, I think that means the "Master Z80 clock" on the CLK pin?  Which is a modern oscillator running on 5V in my case.

The DART was fully intended to run with the CTC generating it's baud clock and the CTC is not capable of 5V output.  It makes no claims over 2.4V.

EDIT:

Although.  That said.  It has been a whlie since I actually checked the master clock.  Not since I asked it to drive 3 more NMOS ICs....

[paulca]

The DART (and CTC/SIO as well), the CMOS versions are like hens teeth, I don't I have seen one.  On discord and vintage computing haunts I see people "walking on past" the NMOS variants as there is a lore they are unreliable, broken or from questionable, random "old stock" sources.

[tggzzz]

Strong 1 master clock pulse at 4.2V.

Datasheet https://datasheet4u.com/datasheet/Zilog/Z8470-656613 indicates clock should be >Vcc-0.6, i.e. >4.4V.

That is sufficient to account for flaky operation.

It also indicates Icc 100mA max, so your 40mA(?) would be well within spec.

The CTC VOH is 2.4V and 1.8mA. 

The DART output VoH is 2.4V @ 2mA.

So I don't know where in that day and age is't getting >4.4V, it's not from it's own family.

Completely irrelevant.

The relevant spec is V_IHC. Note the bold characters.

I don't think that means the baud trigger clock, I think that means the "Master Z80 clock" on the CLK pin?  Which is a modern oscillator running on 5V in my case.

The DART was fully intended to run with the CTC generating it's baud clock and the CTC is not capable of 5V output.  It makes no claims over 2.4V.

EDIT:

Although.  That said.  It has been a whlie since I actually checked the master clock.  Not since I asked it to drive 3 more NMOS ICs....

You were talking about the master z80 clock being only 4.2V; see above.

The "modern oscillator's" Vcc being 5V is irrelevant. The only thing that matters in this context is V_IHC>4.4V.

Have you verified there is no noise on the DART's Vcc and Gnd lines. Signal integrity problems there could lead to flaky operation such as you describe.

[paulca]

I see the confusion.

The CTC goes high for a very short pulse as the timer zeros.  I believe it is high for just 1  master clock duration.

A DART byte looks like:


The CTC baud clock looks like:


The master clock looks like:

(im just holding the probe against a pin)

[tggzzz]

There's no point in checking an analogue output if the PSU rails are incorrect; no surprises there!

Similarly there's no point in checking logic operation until PSU and input signal integrity has been verified.

That means:

• checking PSU rails at the chip for correct voltage and absence of impulse noise (typically caused by transitions)
• checking inputs to see they voltages are valid w.r.t. V_IH and V_IL, and that they don't go outside the PSU rails
• checking input timing, paying particular attention to T_setup and T_hold
• checking clock signals are monotonic, with no excessive overshoot nor undershoot

All those measurements must be done with the scope shield connected to the IC's GND pin by a short wire. Even a 6" lead can cause problems: https://entertaininghacks.wordpress.com/2015/04/23/scope-probe-accessory-improves-signal-fidelity/ and https://entertaininghacks.wordpress.com/2016/09/17/scope-probe-accessory-higher-frequency-results/

Be aware the clock frequency is completely irrelevant; the only important parameter is the rise/fall time. You can get just as many problems with a 1Hz clock as a 10MHz clock. Anthropomorphic explanation: the circuit neither knows nor cares when the next transition might occur.

[paulca]

I'm going to put a checksum on it.

It's bad, I'll fix it.  If it's not, I'll live with it.

I grew up rewinding game tapes 14 times just to get that one clean load and be able to play it.  I may have low expectations of what Im doing here.

The analogy though might be .... cleaning and realigning the tape heads would make an improvement, especially if you aligned them to that tape specifically, by ear.

That would be me cleaning up my UART leads, properly terminating them on my end, rather than a tossed in 100R because it sounded right and ChatGPT said it was "common".

[paulca]

So I went and checked the PSU rails as you suggested.... all full of confidence they were clean.

I found 500mV peak to peak "pulse" noise.  Traced it to the FTDI Quad UART and as it's not connected to VCC.... it's ground... USB ground.

Having never had one work before I thought it was a waste of time and put a USB isolater on it.  It worked and the 500mV noise is gone.  Left with barely triggerably 35mVpp noise on VCC.

[tggzzz]

Left with barely triggerably 35mVpp noise on VCC.

I would expect you could easily trigger on 35mV of noise; certainly I can on every scope I own.

You are using AC coupling when looking at the noise, aren't you? At, say 5mV/div, 35mV would be 7 divisions high.

[paulca]

Left with barely triggerably 35mVpp noise on VCC.

I would expect you could easily trigger on 35mV of noise; certainly I can on every scope I own.

You are using AC coupling when looking at the noise, aren't you? At, say 5mV/div, 35mV would be 7 divisions high.

It triggers, but just shows a persistence blur.  One shooting it and I see these lovely little dragons.


More has been added to the system though, I just plugged a whole breadboard into the bus with an FPGA.  So the situation may have got a little noisier than this avo.

I also had to remove the cheap Rudeng SWPSU and use the Tenma linear to get it that clean.

Now you have me trying to justify a Rigol DP832 to myself.

[tggzzz]

Use infinite persistence, and see the worst case values. That's one advantage of a digitizing scope over an analogue scope.

Get rid of the 20MHz BW limit, and see the higher frequencies. That's imperative for signal integrity assessment.

[rstofer]

You can clean up the deficiencies of ASM by using a Macro Assembler which will allow you to 'invent' your own ops or functions.

https://marketplace.visualstudio.com/items?itemName=mborik.z80-macroasm

I don't have any experience with that assembler but I have some experience with the IBM 1130 Macro Assembler and a ton of experience with the CP/M Macro Assembler.  In the early days of 8080 CPUs, CP/M was the way to get things done.

https://groups.io/g/ballyalley/topic/added_palo_alto_tiny_basic/74146783

I used to bring up 8080 projects by first bringing up Palo Alto Tiny Basic.  I added commands to get and fetch from RAM and wrote functions to interface with IO devices.  Mem(addr) = <something> was a memory write and I = Mem(addr) was a memory read and store.

I would see if CP/M brought anything to the dance and then go looking for the source.

http://www.cpm.z80.de/source.html

[ozcar]

Around 50 years ago I encountered what was practically another language, called TOPSTRAN, which was implemented via a set of IBM System/370 assembly language macros. Incredibly, from what I see now, this could still be in use half a century later.

[brucehoult]

You can clean up the deficiencies of ASM by using a Macro Assembler which will allow you to 'invent' your own ops or functions.

Doing that pretty quickly gives you code that is less efficient than a decent C compiler will give you., even on a Z80. It's going to be hard to do good register allocation, everything will "live" in RAM and be repeatedly shuffled back and forth to registers only for the duration of a single macro (most likely). On a machine with lots of registers (e.g. 32) you can write the macros to take register arguments but on Z80 you don't have a choice but to use A or HL for lots of things. And DE is the only place you can conveniently swap HL to (or TOS but that's much slower of course).

Probably the best practical thing you can do with macros is to use them to implement Forth-like primitives, but with the more important (and shorter) ones inlined rather than calls.

[rstofer]

There is also PL/0 by Niklaus Wirth.  It is a proper subset of Pascal and the thing that makes it worth a look is the syntax diagrams.  You write the compiler directly from the diagrams.  There are similar diagrams for full Pascal.  There is stuff all over the net.  Admire the simplicity of the syntax diagrams.

UCSD Pascal was done that way and was one of the first generally useful high level languages for the 8080.  Then they cancelled everybody's license and sold the rights.  A lot of business developers got hung out to dry.  The runtime was a few hundred lines of ASM.

There is also Intel's PL/M - a language I used to lust over.  It was written in Fortran 66 and compiles with GNU F77.  Source is out on the web.  Major parts of CP/M are written in PL/M while the remainder is written in ASM

Microsoft had a version of Fortran.

Anybody remember PL/I?  Digital Research had a version that ran on CP/M.  It's  out there somewhere.