Following in the footsteps...

[sweh]

Now I have a Gotek I want to be able to have the option of using UPURSFS and MMFS and STL DDFS (and tape, since I've hooked that to the audio on my PC.. and serial port with Kermit... and ANFS... I think I've gone mad, here!).

Now UPURSFS isn't a problem; it sits in my Manager ROM. It's always there. But MMFS and DDFS; there's where it gets more annoying. If I put them both in then PAGE goes up. And who knows how well they'll interact (even if MMFS is well behaved, I'm sure DDFS isn't).

"No problems", I think; I can use my Manager ROM to *UNPLUG one or the other. And this works. EXCEPT...

The Manager ROM needs a few bytes of workspace, and games overwrite the bytes I "stole". It's so normal to end a game and find "Shadow ON; SRDATA ON; all ROMs unplugged" that I added a keystroke (T-BREAK) to reset everything (including wiping SWRAM banks - T for "Total Reset"). This makes it less than an ideal experience. What I need is persistent configuration storage outside of the memory space; basically the CMOS on the Master.

Now I'd thought this before and even updated my "2nd user port" design to handle a 48Z02B (2Kbyte RAM with builtin battery). But I'd got so sick of wire-wrapping and soldering (not my favourite activity!) that I shelved it, unfinished. It's still sitting in a box, taunting me. And using up one of my breadboards that the prototype is setup on.

But then after playing with the 3-LED board a few weeks back and realising how easy it is I started to wonder. Hmm... an Arduino Nano has a small amount of EEPROM space (1024 bytes IIRC). I could create an I2C type connection to that and store my configs there. Dunno how quickly it boots up (would data be available on Beeb powerup?) but worth a try.

Now where to hook it into. I don't want to use the User Port (already for MMFS). 1Mhz bus? Tempting (map the EEPROM into JIM at FD##?) but power is an issue. Serial port? Nope, in use. Joystick port? I had a vague memory there was _something_ there from playing with the 6522 earlier.

And that led me down to MartinB's i2c solution. Where he'd _also_ settled on the joystick port, piggybacking on the joystick fire buttons. Hmm. Interesting!

So it seems I've come to a similar design to Martin's stuff! I want to mount inside but I don't trust my soldering skills (he soldered under the motherboard to the connector) so I'm tapping directly off pins 14/15 of the system 6522, and then stealing +5 and Gnd from PL14 (speech serial ROM).

And, damn, the RTCs are the same price as an arduino nano. So let's get a couple of them as well. See how it works.

I won't be using Martin's ROM (although I may use it to verify I've got the wiring correct!) because I want to embed the communication directly into my manager ROM and I'm not creating a generic i2c solution, but it seems as if I'm following in his footsteps!

Maybe the biggest challenge in this will be the fact I can't use an emulator to test the software. I'm gonna have to be in my basement on the real Beeb, and there's no aircon down there. And humidity is high. Hot'n'sweaty!

[MartinB]

Sounds fascinating Stephen, keep us posted!

One minor point, I have subsequently discovered that because the MOS obviously shares the same system 6522 lines as I have used for my I2C, if you mess with keyboard during certain I2C accesses, you can corrupt a transfer. I can’t ‘break’ anything as such, an affected interchange just bounces but might be something to keep half an eye on.

(Since Stephen has cued me in for a free promo - for anyone curious, the I2C project is here, it’s just a cable and a rom.)

[sweh]

Sounds fascinating Stephen, keep us posted!

On the plus side I plugged a module in and it worked with your ROM first time.

I realised I don't need a battery in this thing 'cos the 32K storage is an EEPROM and I'm not concerned about the RTC. Heh, maybe I could store an ROM image in there and have a command to copy it to SWRam. Or maybe even an RFS-style filesystem... Something to think about as a future enhancement

One minor point, I have subsequently discovered that because the MOS obviously shares the same system 6522 lines as I have used for my I2C, if you mess with keyboard during certain I2C accesses, you can corrupt a transfer. I can’t ‘break’ anything as such, an affected interchange just bounces but might be something to keep half an eye on.

Hmm. Would SEI/CLI around the core routines help?

I also realised I'll need to reset DDRB each time 'cos I can't trust the OS not to change things under me!

[sweh]

Mistake #1. I set up a scope so I can see transitions of SCL and SDA. But to verify my cabling wasn't borked I put one scope probe onto the +5V and another onto GND.

And for some reason the scope wasn't reading 5V.

And then I saw smoke curling out of the body of my precious Beeb. Yoiks! Power off!

Huh, the cable I had on the 5V line melted and that's what was smoking. I guess the scope was pulling more power than the cable could handle. Hmm.

But on the plus side I used Martin's ROM and can see SCL/SDA transitions as it talks. (I noticed the ROM hangs for a long time if there's no device on the bus, but fortunately these adapters have pass-through connectors).

So I'm at least set up to prove I can write simple "SDA high/low" "SCL high/low" functions. Which is the core functionality.

Probably the rest of this week is gonna be working out how to mangle FE42/FE40 to provide these functions. At that point I have low level wire drivers. Step after that will be higher level I2C functionality ("start" "send byte/get ack", "receive"). Which is the hard part!

[BeebMaster]

And then I saw smoke curling out of the body of my precious Beeb. Yoiks! Power off!

I didn't realise at first that you meant following in my footsteps...

[Colday]

Mistake #1. I set up a scope so I can see transitions of SCL and SDA. But to verify my cabling wasn't borked I put one scope probe onto the +5V and another onto GND.

And for some reason the scope wasn't reading 5V.

And then I saw smoke curling out of the body of my precious Beeb. Yoiks! Power off!

Huh, the cable I had on the 5V line melted and that's what was smoking. I guess the scope was pulling more power than the cable could handle. Hmm.

I was under the impression that a scope doesn't pull any power (or if it does extremely negligible) as it has it's own power source.

To melt a beeb power wire that has to have been way higher current than what a scope would pull. I connect my scope regularly between ground and +5v without a problem.

I've even created some soldered extenders that fit between the vcc connector (or ground) and the power cable.

Sounds as if there may well have been a short on that line somewhere.

[cmorley]

To melt a beeb power wire that has to have been way higher current than what a scope would pull. I connect my scope regularly between ground and +5v without a problem.

The model B's PSU ground is earth referenced. The ground on a scope is also earth referenced. If you misconnect the scope ground to the 5v you will short the power supply back through the earth of your mains house wiring.

Lots of modern electronics doesn't have earth referenced PSUs (anything with a figure eight power cord for example).

[Colday]

To melt a beeb power wire that has to have been way higher current than what a scope would pull. I connect my scope regularly between ground and +5v without a problem.

The model B's PSU ground is earth referenced. The ground on a scope is also earth referenced. If you misconnect the scope ground to the 5v you will short the power supply back through the earth of your mains house wiring.

Lots of modern electronics doesn't have earth referenced PSUs (anything with a figure eight power cord for example).

Yes, so directly shorting the vcc supply to ground through incorrectly connected scope? Did I read that correctly?

[sweh]

To melt a beeb power wire

It wasn't a beeb power wire; it was a simple jumper wire that would normally have gone from 5V to VCC on the i2c device.