6502.org

The I²C 24xx 8-pin EEPROM family goes up to 128Kx8 (24xx1024) AFAIK. There may be a bigger (ie, denser) one by now but I²C ones are not likely to get very big due to I²C's speed limitation. I²C can be interfaced with only two pins of a 6522, which is much, much easier than compact flash. Up from that you can get ones like the 25VF032 4Mx8 SPI (which goes nicely on 65SIB) flash in an SO-8 package, which I bought last year for $2.56 each.

I don't want to dampen your enthusiasm but don't forget, when comparing speed with early 80's micros, that your system doesn't have to spend time writing data to the screen, it simply has to write a byte to the ACIA and that's it, job done. Most early 80's systems needed the CPU to calculate cursor position and write data to the screen - this takes time. And since many of them didn't have hardware scroll, scrolling the screen could take absolutely ages. A system that doesn't have to do this will naturally be much faster.

Well done for getting the unit going and don't worry too much about what the wiring looks like - the fact that it works is the important bit.

Various ideas spring to mind... I think the convention on this system is to pad with ten NULs - after the CR and before the NL. Can you increase that number, to compensate for the high baud rate? Location FFB0 is the number in question. (Or, you could process the file on the windows side to add lots of NULs, as a test of the principle.)

The ACIA has RTS/CTS tied off, and to make use of them you'd need to level-shift. Maybe that's out of bounds. If you were to try to use them, perhaps check out MartinB's findings in this thread on the StarDot forums. I've certainly seen odd things with Windows driving serial into the Beeb, where Linux behaves more predictably, but I haven't ruled out hardware differences yet.

The other flow control method is XON/XOFF - Hyperterm can do that, I'm not sure whether or not CEGMON can do it.

Finally, perhaps you can arrange to throttle the speed at which you send data. I can't see a serial program that can do that. You could do it if you sent your data using say python, but would it be worth the bother. I suspect stuffing lots of NULs in might be preferable - or rigging your ACIA for a lower baud rate.

(The CEGMON manual is here [pdf])

No, Paul, I didn't forget - well, I mean I did - but I remembered when I was enthusing about the speed to a colleague. Heh, heh...
Thanks!

TTo be honest, the look of the wiring is not as important as ensuring its longevity; that is what I am interested in. There are several temporary bodges on there I need to fix, and tying the wires down will prevent them getting snagged on something when I am moving the board about. It'll end up in some sort of case at some point but for now it's a bare board (as they were sold in the 70's).

Thanks Ed. I have only done a quick test using spaces to pad. Nulls are up next (when I work out how to insert them in Windows). I guess it can't be long until I am using Linux for this, because Windows sucks if you're a Unix hacker like me. It's the baud rate, of course. Since there's no flow control at all it's going to be tricky. CEGggie might support it (don't know about this version, Grant hacked it up a bit to get it to only use the serial port) but as you say the ACIA isn't wired appropriately. I need to read the ACIA datasheet.

Another possibility lies in turbo boosting (ha ha) the processor so it's quick enough to deal with the incoming torrent of text from the ACIA. The Motorola CPU is rated at 2Mhz - if the memory is fast enough it ought to work. I already asked how to speed it up (use the 2Mhz clock output from the counter). I foresee a "turbo" button like those old 33/66Mhz PCs..

I notice the ACIA is run in the CLK/16 mode - you could POKE it to run at CLK/64 mode, which would turn it down a bit.
So you'd want to POKE the value 16 to location 15*4096 to run at a quarter the baud rate.

Ah, I also notice Grant says he's NOPped out the code to write NULs to the output stream. So you have to replace them anyhow.

Do you have Activestate python installed? You could reinstate the NULs fairly readily with that, I think. Something a little like this perhaps:

I'll give it a go. Can it not be made to work with flow control? I guess the ROM would need a patch for that, plus some rewiring. How would that be implemented? I guess set CTS just prior to polling for new characters and RTS before sending.
Yes, agreed. But when I do save or load it comes back OK and does nothing. Reading the manual, it appears as if save / load set the ACIA mode for I/O.
I'll use C or C++ I think.. But that looks reasonable (me not being a Python progger).

Hmm. If 10 NULs were needed at 300 baud, then at 19200 you'd need 640 NULs (which should be enough for anyone.) This seems absurd!

Are you saying that BASIC fails to capture any of the LOADed program? So it's a case of severe data overrun? The input routine doesn't seem to apply any buffering at all, or have any check for overrun.

The normal story for flow control, I think, is that RTS (or XOFF) is used by the receiver to tell the transmitter to shut up. The transmitter will then shut up, at its discretion, at some future point. So you need to have a system which reads characters into a buffer, and which applies RTS before that buffer fills up. It's the interrupt routine which fills the buffer, and the OS call which reads from it (under disabled interrupts, to avoid a race.) This is tricky stuff, and I think it's just missing from CEGMON - running at a lower baud rate, compared to the CPU speed, or adding NULs, is the workaround.

Unfortunately, executing POKE 15*4096,16 didn't work. I stopped responding, and when I reconnected at 4800 baud I got nothing. Had to hit the (newly installed) reset button, which bought it back to 19200. Seems I need a sending program that puts a delay between each line. A delay before hitting enter seems to work - pasting a line into the terminal sends it correctly to the MUK101. Of course, the problem is that the terminal owns the rs232 port so it needs to be disconnected during the send. Hmmmm.

Since I'm now using OSX I should be able to just take the program and cat it to /dev/tty[whatever] with a delay between each line. Thus:
By the way it doesn't work, presumably because the port's not setup.

That's much the sort of thing I was doing, in linux talking to my beeb, before I figured out how to set the buffer size right so the flow control worked.

But - in OSX, if you're using Zterm, there's an option called 'text pacing' which just might be worth a try. In our case, it was just slowing things down, but that's what you want.

I wonder - you could perhaps patch the ROM to send XOFF when it sees a CR and then XON when it sees a NL, if inbetween times BASIC goes away and tokenises and stores the lines, and allows any NULs to get dropped.

in python you can do this kind of thing not sure how you do it in shell

Well, apparently like this
.. but it does not seem to work.

This script replaces LF in the input file to CR/LF which the UK101 expects.
Sending converted files in ZTerm (OSX) with character pacing set to "wait for echo" and line delay of 20 (sixtieths of a second) appears to work.

But... the UK101's BASIC implementation appears to limit the line size to 72 chars, so longer lines are truncated. Or maybe it's CEGMON. Is there a way round this?

[EDIT] Nope, it's the UK101's BASIC. The manual says "up to 71 characters on any line". That's a pity. I have a text based adventure game written in BASIC that I'm trying to resurrect - will have to cut the longer lines up...

See viewtopic.php?t=1819 for the adventure game I mentioned. I have got it up & running on the UK101 at last..

Just a brief note to let you know I overclocked it to 2Mhz (by moving the processor's clock in signal from Qd to Qc on the 74LS93) this morning and it is working fine.

Wow. TURBO power or what?


[EDIT : Actually, tell a lie, it just crashed running my adventure game. BACK TO THE DRAWING BOARD to check the memory access speed... ]