exxos's Atari, Amiga & retro forum

With the arrival of the phone screen adhesive tape today I've finally finished the repair of my Dad's Google Pixel XL, with the total cost, including an original HTC branded battery, of less than £20.

The phone repair bloke in Truro covered market was quoting over £200 as he said that he'd have to break the screen, which would be £150, plus £60 for the battery.

It was a bit tricky getting the screen off but with the use of a hair dryer to warm the adhesive and an old credit card to run underneath the glass and cut the rubberised gum it came off without damage.

Hmm... The more I think about this Apricot disk interface emulation the more complex it becomes.

The memory buffer part is pretty simple, a couple of 74LS373 bidirectional buffers, a CD74HCT4020E 14 bit counter, 32Kx8 SRAM (only 8Kx8 used for the data) and an inverter, controlled by signals elsewhere.

Host address decoding will need a whole ATF22V10 all to itself with an 74LS272 (or is it 273) to isolate it from the address bus if there's not an I/O read or write cycle, which will probably have to be controlled by a 16V8.

But this is the easy stuff. Having the ability to use another part of the SRAM for virtual WD1010 registers, being accessed both by the host and by the Raspberry Pi feels dauntingly complex. I may need another couple of 373s and 272s too so as to allow dual porting of this RAM. This is going to need lots of chips I think and I don't know if there will be enough space on any card I can fit in the machine.

I've come to the conclusion that I can't use the buffer SRAM for the registers. During a buffer fill or empty operation by the virtual disk controller the host will be polling the status register constantly and given that the Raspberry Pi or whatever I put at the other end is likely to be too slow to react to any signals to stop access half way through a read or write it's not going to be possible.

However, there's still the problem of the virtual registers which need to be effectively dual ported. The host writable registers are less of a problem as they're written to infrequently and only need to be read by the Pi if the command register has been written to. However, the host readable ones can be read by the host at any time without warning and a Pi write cycle is likely to be slow enough that there's a high probability of a collision, especially when the host is polling the status register to see if a transfer has completed. I can't really afford the PCB space for 16 8 bit latches.

Does anyone have any ideas?

I s'pose I could use a dual port static RAM chip (7130), but they are expensive at about £10 each on Mouser, and they're end of life too, for at least the DIP48 version.

OK, I think I will have to go with the dual ported SRAM for the registers. There's no other reliable way of doing this.

I've been rethinking the address decoding. I think that I'm just going to use and gates an inverters as it's pretty simple.

From what I can see in the ROM the disk interface is the highest I/O address on the system. i.e. there's nothing else above 0x00de (even addresses only as it's only using the lower byte of the 16 bit data bus). This makes the decode easy as I merely have to and A5, A6, A7 and the signal saying that this is an I/O operation to wake up. I can then use A8 to determine if this is aimed at the simulated WD1010 (0) or the registers/data buffer (1). Then I can differentiate between the registers and data buffer using A4. i.e. 0x0e? == WD1010, 0x1e? == registers, 0x1f? == buffer address (technically I should test that ? is 0 but who cares?).

By taking the address decoding away from the GAL it frees up a lot of the input and output channels. The outputs are especially important as I need 8 output from the control signals controlled by the 1 bit control "register" writes, these include the head address, resetting the buffer address counter and selecting whether the host or disk has access to the buffer. This leaves two outputs on the 22V10 for other signals.

As for the interfacing between the TTL and 3.3V (Raspberry Pi) I'll have to use SN74LVC245AN chips powered from the Pi's 3.3V output. They are 5V tolerant for input.

Just ordered an ISA/PCI BIOS POST diagnostic card from eBay. Hopefully it'll give me a hint as to why the 486 seems not to want to play until I hit the reset button after it's been left off for a while. It may also tell me why it sometimes halts after rebooting just after it seeks the floppy. I'm guessing that it's waiting for one or other of the hard drives as when the problem happens I don't hear the drives seek.

P.S. The eBay listing specified "Location: London" but after buying it said that it was shipping from China. *sigh*

A bit of a change today... Going 8-bit.

I'm just getting the Amstrad DDI-1 interface and FD-1 drive ready to donate so having "fun" trying to create a utility floppy.

As you can see here, I have the Gotek as drive A: and the FD-1 drive as drive B:


Well, it took me ages to find a way of formatting and copying to drive B:. Not only having to rejuvinate tired old 3" floppies using the trick of trying to format them with IPA sprayed on the surface (helps remove the thin oxidised layer from the top of the surface), which succeeded completely, but finding a way to actually do the format.

The format program which comes with the DDI-1's CP/M is hard coded to format disks in drive A: only. A bit of a problem when drive A: is a Gotek. I didn't have a working 3" system disk so I couldn't just run as a single drive.

However, the CP/M 2.2 disk which came with the CPC6128 has a different way of formatting etc. It has a program called DISCKIT2, which formats, copies and verifies disks. So, booting into this image I as able to format the two sides of the "new" floppy disk and clone it onto the drive. Reboot, put the original DDI floppy image on the Gotek, boot from that and run B:DISCKIT2, from which I could duplicate the DDI floppy side 1 and side 2 images in turn. Job done.

Woo... It looks like the tag SRAM chip has arrived in the UK and cleared customs.

stephen_usher wrote: 24 Jan 2022 15:14 Woo... It looks like the tag SRAM chip has arrived in the UK and cleared customs.

:yay2: :dualthumbup: :cheer:

It feels as if everything is in courier limbo at the moment.

I'm waiting on the delivery of not only the QS8888 but also ISA/PCI BIOS post diag card (looks like Chinese eBay seller pretending to be in the UK) and a 486DX2-66 "Overdrive" CPU. Then there's the package I sent to someone yesterday.

Sigh