Home Page Forums MAME MAME Triumph-Adler alphatronic P3 (+ P1, P2 and P4)

The cursor looks great now, and thanks for catching my copy/paste error.

Here (and on the FTP) is an archive of P2 disks: https://mega.nz/#!yB5TCbJZ!mBRDCXFVOQNKRT5-UVIfbxbehJC1RSo1EmcKP8x6AwA

It looks as if the P2's have problems with the disk ready signal - formatting the disk in drive 1 just hangs, whereas trying to format in drive 2 explicitly mentions a drive that is not ready.





To replicate this situation, insert the disk "P2_ssdd_basic_foko_disk_util.IMD" from the archive, boot the FOKO disk utility by entering "B1" at the MOS prompt and try to format a disk in either drive 1 or 2.

All dev folks, thanks for your patience and expertise!

A quick addendum to the HSYNC/VSYNC used in the P2:

helwie44 measured them off his P2U using a port extender and logic analyser:





He writes: "Here is the original 15.15 kHz HSYNC to the 8085, i.e. there's an interrupt from the CRT to the CPU every 66µs. But in reality those interrupts are being processed only when needed on the P2 - a mask opens the RST55 e.g. in case a scroll is needed".

He's outlined the mechanism in handwritten notes which I've uploaded here and on the FTP.

Background on using HSYNC and VSYNC
in the Alphatronic P3 / P30 and P2 / P2S / P2U systems

With the TA P3 / P30 systems only those with a RIM (i8085) the signals VSYNC: = int6.5 and / or HSYNC: = int5.5 are polled. In order to make an input or output to the DISPLAY memory. No real interrupt is used for the diplay transfer. Since the VSYNC was already installed in the alphatpx.cpp, the display output started almost immediately.

The MOS in the EPROM 1000h-17FFh of the P2 series is a bit different.
The text output (characters) takes place via the real INT6.5 of the picture key gaps (approximately period 20ms). The output prepares the necessary parameters and puts out a HLT (i8085). Then, with a triggered int6.5, the service routine will process the character output.

But as soon as a "rollup" is triggered, this is initiated via the VSYNC via int5.5. Therefore, the first image output hung first. (wait until finally - because no int5.5 was set up by the MESS!)

Unfortunately, the mechanism available by now HSYNC is due to bad time response of user input / etc.

I already had a patched original TA EPROM "14G" signature some time ago to change the IMASK from 0Eh (int5.5 open) to IMASK to 0Dh (int6.5 open) just one byte in the rollup area.

Here theDisplayDriver EPROM "14g" as .bin,
and a pdf of the patch hexadump with references.

All display requirements are only processed via the VSYNC, ie the int6.5. The result is very good.
Thank you for all contributions and valuable help.
The reaction speed is exactly like the P3 / P30 machine.

I was allowed to dump disks and ROMs from a very special Alphatronic P1 ... sn#00001 that used to be the office PC during the 80s in a shop in my hometown:

http://kaufhaus-konrad.de/geschichte/rechenknechte/461-2/



If you go by the books, the P1 is a cost reduced version of the P2 with only 32K upper RAM and only one 160K flopy drive. According to the owner, this specimen already came topped up to 48K and was later treated to a second floppy drive. helwie44 thinks it might be a rebadged SKS KISS or a preproduction unit. Note the TV modulator and the connector for a cassette player, which my P2s don't have.



Photos, MOS dumps and a dump of the character ROM are on the FTP and here.

One of the two disk dumps has loads of read errors, but boots the BASIC and FOKO disk utility fine. The other one points to a preproduction unit again, as it is an 80K, single sided, SINGLE density disk. It doesn't boot at the moment in the P2 emulation.

I've added the P1 ROMs to the driver, using the P2 keyboard ROM as I wasn't equipped to read a 1702A keyboard ROM on the day. The MOS comes up, but seems to receive constant keypresses from the "wrong" keyboard ROM.

I'll revisit the P1 once I can reliably dump 1702A's and bring my Kryoflux (and maybe a working P2) to obtain a better copy of the damaged disk.

It would be great if someone could address Vas' requests in my commit in the Alphatpx driver ... I've tried all morning but I'm getting nowhere - sorry!

https://github.com/mamedev/mame/pull/3139

in the constructor:
m_floppies(*this, "fdc:%u", 0)

public:
optional_device_array<floppy_connector, 3> m_floppies;

than access with
m_floppies[0] to m_floppies[2]

Thanks, Duke ... this looks easy enough, but I'm still at sea

- I'm not sure this is the replacement that Vas meant in the alphatp_12_state for the m_con variables unless it applies there as well
- as a first step I tried to replace m_floppy0 and m_floppy1 in the alphatp_34_state but it seems there's more involved than exchanging m_floppy0 for m_floppies[0]

Seems to be a bit of a mess. alphatp_12_state now has 5 floppy connectors. I'm guessing alphatp_12_state needs 3 floppies and alphatp_34_state needs 2? Then remove m_floppy0 and m_floppy1 from alphatp_12_state and use the device_array (why is it optional? p1 has no floppies or something like that?). m_floppies[0] is the same as m_con1 then.

Thanks, slowly getting there ...

I've reduced the number of floppy drives for the P1 and P2 to two ... unlike the ITT3030 from which this part of the code was copied, the Alphatronics have no provision for a third external floppy drive.

So out go m_floppy1 and m_floppy2, as well as the m_con stuff, in goes a required_device_array<floppy_connector, 2> m_floppy; and a matching m_floppy(*this, "fdc:%u", 0)

m_floppy[0] et al. replace m_con1 et al ... what I'm left with is this error message that is repeated for the second floppy connector:

You're supposed to delete that line - the drive gets looked up at object resolution time so you don't need that line in the the start handler.