Eric HertzThere's a reset pin in the RS232 connector?! Also, definitely a bit loopy.
Oh, heh the resistor on PIOBPpin34 is tied high. And before the bodge, that's the only thing that was connected to that PIO pin by-design.
Also, I haven't read up on this particular Timer/Counter, but feeding an input into it at the same frequency the Counter/Timer is driven (via CLK) seems like it's asking for weird aliasing effects, or worse, unless I suppose they're asynchronous?
Also, not grasping why these I/O devices all need /M1; it's available on the expansion-header, as well. Oh, maybe for the weird Z80-Peripheral IM2 scheme?
....
Alright! Did some 'scoping!
CTC pins 9,22,23 seem always at about 1.2MHz. ~28us high, 56us low.
CTC pin 20 appears always high (pulled-up?) BUT, I stopped checking after the first few tests (anyone have reason for me to be more thorough with that one? The PIO might drive it?).
CTC pin 7, obviously, is where it's at...
If I didn't make any translational errors:
(M# corresponds to the measurement number. It's only here for my transferring notes)
M2 110: Immeasurable, looks low
M4 300: ~86.2KHz
M7 600: Immeasurable, looks low
M3 1200: Immeasurable, looks low
M5 2400: Immeasurable, looks low
M8 4800: ~152KHz
M1 9600: ~300KHz
M6 19200: ~610KHz
(Surely I must've swapped 300 and 2400 somewhere, in testing)
Otherwise, it looks reasonable, doubling with the baudrate... 32x faster... wait, didn't I hear the DART doesn't have a divide-by-32? Huh.
The ones I could see all have a 28us high pulse, (matching the 1.2MHz presumed-input. the remainder of the time it's low.
Heh, I guess that's all I have to report after hauling the thing and the scope to an outlet only to find out the thing's power switch is on the front panel back in "the shop". But, it was for the better, because when I got back the blaring sun was mostly blocked by a nearby building.
Also ran some scoping on the AMD, which I'll throw in a previous log about that guy.
Discussions
Become a Hackaday.io Member
Create an account to leave a comment. Already have an account? Log In.
I kinda dig their watching for RETI, kinda makes me want to think about other hacky that could be done by watching ingoing instructions. May be a bit like an 8087 FPU extending the 8088's instruction-set by intercepting them.
In my <a href="https://bestwoodglue.info/">I bought wood glue</a> and I will make a amazing boxes
Are you sure? yes | no
needing /M1: yes it is for the weird IM2 scheme.
Normally, M1 is the 'opcode fetch' phase and comes from memory. However, if M1 and IORQ, it's the interrupt vector request phase. Also, even during regular instruction fetches, the peripherals are 'sniffing' the instruction stream for the RETI sequence, which is the interrupt acknowledgment phase.
You mentioned that those signals are on the expansion header. However, I was reading the manual and Zilog recommends against more than 4 devices in the chain due to propagation delays in the EIEIO, and if needed then using some additional circuitry to handle that, which we don't have.
I learned a thing: the datasheets are incomplete. This caused me some trouble last week. What you additionally need are the respective 'Technical Manual's for the various peripheral chips. I'll put them in the files for convenience. I couldn't find one for the DART, but the SIO is pretty much the same when it comes to async.
Are you sure? yes | no
Right on. Another "Well, that just makes sense, now that you put it that way" explanation, thanks.
I kinda dig their watching for RETI, kinda makes me want to think about other hackery that could be done by watching ingoing instructions. Maybe a bit like an 8087 FPU extending the 8088's instruction-set by intercepting them. Interesting!
Awesome, thanks for uploading those docs, and the hard work in determining that and where to look for greater detail!
In my shopping spree I bought a ream of paper, heh! Soon #The Artist--Printze might be put to use as originally-designed!
I also did some scoping, results have been added, above.
Are you sure? yes | no