Previous Thread
Next Thread
Print Thread
Page 6 of 9 1 2 3 4 5 6 7 8 9
Joined: Jan 2012
Posts: 1,162
Likes: 7
rfka01 Offline OP
Very Senior Member
OP Offline
Very Senior Member
Joined: Jan 2012
Posts: 1,162
Likes: 7
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.

[Linked Image]

[Linked Image]

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!


NCR DMV- DEC Rainbow- Siemens PCD- ITT 3030-Oly People- Acorn A5000- Olivetti M20
Joined: Jan 2012
Posts: 1,162
Likes: 7
rfka01 Offline OP
Very Senior Member
OP Offline
Very Senior Member
Joined: Jan 2012
Posts: 1,162
Likes: 7
A quick addendum to the HSYNC/VSYNC used in the P2:

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

[Linked Image]

[Linked Image]

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.


NCR DMV- DEC Rainbow- Siemens PCD- ITT 3030-Oly People- Acorn A5000- Olivetti M20
Joined: Nov 2017
Posts: 8
H
Member
Offline
Member
H
Joined: Nov 2017
Posts: 8
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.

Joined: Jan 2012
Posts: 1,162
Likes: 7
rfka01 Offline OP
Very Senior Member
OP Offline
Very Senior Member
Joined: Jan 2012
Posts: 1,162
Likes: 7
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/

[Linked Image]

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.

[Linked Image]

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.


NCR DMV- DEC Rainbow- Siemens PCD- ITT 3030-Oly People- Acorn A5000- Olivetti M20
Joined: Jan 2012
Posts: 1,162
Likes: 7
rfka01 Offline OP
Very Senior Member
OP Offline
Very Senior Member
Joined: Jan 2012
Posts: 1,162
Likes: 7
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


NCR DMV- DEC Rainbow- Siemens PCD- ITT 3030-Oly People- Acorn A5000- Olivetti M20
Joined: May 2004
Posts: 961
Likes: 23
D
Senior Member
Offline
Senior Member
D
Joined: May 2004
Posts: 961
Likes: 23
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]

Joined: Jan 2012
Posts: 1,162
Likes: 7
rfka01 Offline OP
Very Senior Member
OP Offline
Very Senior Member
Joined: Jan 2012
Posts: 1,162
Likes: 7
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]


NCR DMV- DEC Rainbow- Siemens PCD- ITT 3030-Oly People- Acorn A5000- Olivetti M20
Joined: May 2004
Posts: 961
Likes: 23
D
Senior Member
Offline
Senior Member
D
Joined: May 2004
Posts: 961
Likes: 23
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.

Joined: Jan 2012
Posts: 1,162
Likes: 7
rfka01 Offline OP
Very Senior Member
OP Offline
Very Senior Member
Joined: Jan 2012
Posts: 1,162
Likes: 7
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:

Code
../../../../../src/mame/drivers/alphatpx.cpp:1027:58: error: no match for 'operator=' (operand types are 'device_finder<floppy_connector, true>' and 'floppy_connector*')
  m_floppy[0] = machine().device<floppy_connector>("fdc:0");
                                                          ^
In file included from ../../../../../src/emu/emu.h:70:0:
../../../../../src/emu/devfind.h:453:7: note: candidate: device_finder<floppy_connector, true>& device_finder<floppy_connector, true>::operator=(const device_finder<floppy_connector, true>&) <deleted>
 class device_finder : public object_finder_base<DeviceClass, Required>
       ^~~~~~~~~~~~~
../../../../../src/emu/devfind.h:453:7: note:   no known conversion for argument 1 from 'floppy_connector*' to 'const device_finder<floppy_connector, true>&'
../../../../../src/emu/devfind.h:453:7: note: candidate: device_finder<floppy_connector, true>& device_finder<floppy_connector, true>::operator=(device_finder<floppy_connector, true>&&) <deleted>
../../../../../src/emu/devfind.h:453:7: note:   no known conversion for argument 1 from 'floppy_connector*' to 'device_finder<floppy_connector, true>&&'
../../../../../src/mame/drivers/alphatpx.cpp:1028:58: error: no match for 'operator=' (operand types are 'device_finder<floppy_connector, true>' and 'floppy_connector*')


NCR DMV- DEC Rainbow- Siemens PCD- ITT 3030-Oly People- Acorn A5000- Olivetti M20
Joined: Feb 2004
Posts: 2,383
Likes: 98
Very Senior Member
Offline
Very Senior Member
Joined: Feb 2004
Posts: 2,383
Likes: 98
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.

Page 6 of 9 1 2 3 4 5 6 7 8 9

Link Copied to Clipboard
Who's Online Now
2 members (judge, MAMEBase), 20 guests, and 3 robots.
Key: Admin, Global Mod, Mod
ShoutChat
Comment Guidelines: Do post respectful and insightful comments. Don't flame, hate, spam.
Forum Statistics
Forums9
Topics9,103
Posts119,280
Members5,019
Most Online890
Jan 17th, 2020
Our Sponsor
These forums are sponsored by Superior Solitaire, an ad-free card game collection for macOS and iOS. Download it today!

Superior Solitaire
Forum hosted by www.retrogamesformac.com