Ta. Yes, it looks like it uses &A000 as a RAM copy of the bank paging register (the equivalent of &F4), and uses &FCFC as the paging register (the equivalent of &FE30). So, presumably, it doesn't simply plug into a ROM socket, it will need to plug into somewhere else as well to get access to &FCFC. Edit: which must get cleared at RESET as only the code at the start of the image has a ROM header, so bank 0 has to be paged in at RESET for the MOS to be able to recognise it as a a sideways ROM.

It also looks like it tramples on language workspace as well, so a simple *HELP may well kill a foreground application. Edit: unless the bank swiotching only occurs when it itself is the language, then it naturally does own the language workspace and do whatever it likes with it.

The CLICK ROM is a 32K x 8 device and is mapped into the Electron memory as 4 x 8K pages in the address range &8000 to &9FFF. In a similar manner, the Battery backed static RAM device is mapped into the address range &A000 to &BFFF.

And the MC146818 RTC is at:

The Calendar RAM and Registers etc are addressed by setting firstly the Address Register at &FCF8 and then reading or writing the data at the Data Register &FCF9.

I'm having to re-write the cartridge interface to support this, as the current one simply caters for 2x16K ROMs. Since a cartridge is mapped to two pages how does it know which page is being requested? From the cartridge slot pinout it looks like the ROMQA line would be used for this, correct?

If it is the ROMQA line then from the Click board traces posted by Phill it looks like this is not connected. Would that mean the Click ROM appears in both pages? Anyone have one of these to confirm behaviour?

There's a problem with the RTC. The same MC146818 is used in the Master but the Master handles the 21st century much better, though displays 19xx but gets the days of week and month correct. Click displays rubbish for month. Need to investigate this a little.

Now that I have a well defined cartridge interface I can proceed to implement many other Electron cartridge devices. I've already done the ABR which seems to work well.

Moving onto the many disc interfaces AP3, AP4, Pegasus400, Cumana, SEDS, etc. Was the hardware in any of these the same? Why did Slogger produce the Pegasus and SEDS, any difference apart from the ROM?

daveejhitchins wrote:I'm the keeper of a few Slogger 'Click' PCBs belonging to Dave (Arcadian). Maybe if someone would like to 'refurbish' one and document the procedure ???

Dave H

I serviced a Slogger Click cartridge for a user a few years ago. The PCB used in that Click cartridge had a fair few differences compared to an unused Slogger 'Click' PCB that I got from Dave (Arcadian).

Pernod wrote:Moving onto the many disc interfaces AP3, AP4, Pegasus400, Cumana, SEDS, etc. Was the hardware in any of these the same? Why did Slogger produce the Pegasus and SEDS, any difference apart from the ROM?

The PCB, the glue logic and the disk controller hardware of the AP3, AP4 and AP34 is the same. The difference being the position of a selection link (jumper shunt). The EPROMs fitted and whether a SRAM chip is fitted. It's not the same as the Pegasus400, but both provide similar facilities.

Here are some photos of my AP3 that I upgraded to a AP34:-

AP3 (upgraded to a AP34) showing label side of case

AP3 (upgraded to a AP34) component side

AP3 (upgraded to a AP34) close up of ICs

AP3 (upgraded to a AP34) close up of the link

Somewhere (maybe in the forum) there is information on upgrading an AP3 or a AP4 to an AP34. But I forget where

1024MAK wrote:I serviced a Slogger Click cartridge for a user a few years ago. The PCB used in that Click cartridge had a fair few differences compared to an unused Slogger 'Click' PCB that I got from Dave (Arcadian).

Don't suppose you noted the differences? Would the owner of the Click be willing to do some reverse engineering or allow someone else to do it? I also have a 'part-built' Click, with lots of links - Prototype, presumably!

As for SEDFS, I can't remember if the Slogger ads listed full disk interfaces with SEDFS fitted - but anyone with some old Electron User mags to hand should be able to quickly find this out.

When I acquired the Slogger stuff in 2008, there were a bunch of cumana interfaces and boards, some of which had the SEDFS fitted (the ones in the metal cases that contained SEDFS didn't feature the big cumana sticker on the metal case - so it's possible that Slogger sourced boards and unlabelled cases direct from Cumana and re-sold them with their own SEDFS rom). I also found a couple of loose Cumana boards in amongst everything with SEDFS rom but no battery, so as the battery wasn't necessary for SEDFS I suppose it's possible that if/when Slogger supplied SEDFS interfaces they did so with no battery fitted?! This is just speculation though ...

Arcadian wrote:I also found a couple of loose Cumana boards in amongst everything with SEDFS rom but no battery, so as the battery wasn't necessary for SEDFS I suppose it's possible that if/when Slogger supplied SEDFS interfaces they did so with no battery fitted?! This is just speculation though ...

The battery would be for the RTC, and since SEDFS didn't provide *DATE then no need for it.

Now have SEDFS and the Cumana DFS working, both use the same Cumana interface:

Cumana

This is useless without the an image of the Cumana Utilities disc, as it contains the formatter for this unique format: 80 track 9 sectors of 512 bytes. So if anyone has it then we need to somehow get an image of it so that I can add support for the format.

SEDFS

It's nice to see that SEDFS handles the 21st century!

I posted elsewhere that the Sound Expansion cartridges are also emulated. Are there any other cartridge devices to emulate?

Was thinking Solidisk ADFS Winchester hard drive emulation for the Elk (the Solidisk disk interface which contained the dual DFS/ADFS rom you've emulated also contained a 'Winchester' socket - basically a 1Mhz bus I think, that allowed you to hook up Solidisk's own Winchester drives).

Pernod wrote:But it also has 16K SWR on-board, I have no idea how this is made accessible. Any ideas?

Are you sure this isn't olverlaid to provide DFS/ADFS workspace? You could try using ADT's *MEX command.

There doesn't seem to be any space to have the RAM overlaid, and both DFS and ADFS work fine without it. There's discussion on the SWR at viewtopic.php?f=42&t=8824&p=97507#p97457 that suggests it's unreliable. Maybe is overlays either the DFS or ADFS that isn't currently in use, don't understand how though. This photo