Triumph-Adler alphatronic P3 (+ P1, P2 and P4)

I got another CP/M machine from a German company: The Triumph-Adler alphatronic P3.

MAME already supports its little homecomputer brother, the alphatronic PC and its distant cousin, the ITT3030

[Linked Image]

The P series machines and the ITT3030 were designed by SKS Steinmetz, Krischke Systemtechnik GmbH who sold P2 lookalikes under the "KISS" moniker.

The very suave SKS nano 2500 in its bordeaux red leather case shares some of that DNA as well, more about that later ...
SKS Nano 2500 which would make a nice addition to MAME as well

This brochure

ftp://ftp.informatik.uni-stuttgart.de/pub/cm/alphatronic/alphatronic-Micro.pdf

has the specs for the P series: They're all 6MHz 8085 machines.

P1: Integrated Keyboard, 6K PROM, 1K RAM internal, 32K RAM, 1x160KB Floppy SSDD
P2: Integrated Keyboard, 6K PROM, 1K RAM internal, 48K RAM, 2x160KB Floppy SSDD
P2 S: Integrated Keyboard, 6K PROM, 1K RAM internal, 48K RAM, 1x320KB Floppy DSDD
P2 U: Integrated Keyboard, 1K RAM internal, 64K RAM, 2x320KB Floppy DSDD
P3: Modular (external KB/Monitor), 4KB ROM, 64KB RAM, 2x800KB Floppy DSQD
P4: Modular (external KB/Monitor), 4KB ROM, 64KB RAM, 1x800KB Floppy DSQD
1x HD 12,5 MB

Alphatronic P30 and P40 were P3 and P4 which were extended by an 8088 coprocessor card and extra RAM.

They have a serial printer port via the 8085's SID/SOD pins and a universal serial interface via a 8251.

http://www.old-computers.com/museum/computer.asp?c=485

This is the Video/keyboard interface, and you can see the similarity with the ITT3030's cards

[Linked Image]

The bus is called "MC-80" in the P2 documentation which also lists its pinout on PDF page 17.

Documentation for the P series as well as disk images for the P3 and P4 can be found here

ftp://ftp.informatik.uni-stuttgart.de/pub/cm/alphatronic/

and here

http://oldcomputers.dyndns.org/public/pub/rechner/ta/

The P3 ROM images presented here should be taken with a grain of salt, they're 3x8KB, where the documentation states clearly that the P3 only has 4KB, and this is what can be found in my machine.

The BIOS and Chargen ROMs of my P3 along with photos of the cards can be downloaded here:

https://mega.nz/#!iZABGbTQ!xh2cRVIpFsyu0NGkghk8P_wS1WMbvYTUS1PFwfb9KnA

Edith says: Don't forget to dump the 8041 keyboard controller! https://mega.nz/#!zEI3HAjY!mzJwXb4yXhJkT101j6LmoFXtUgNaF7HawbpwdoAuTMI

One of the hardware designers of the alphatronic P2 has a website with loads of information on that machine, his role in its genesis and the family tree of the SKS machines.

http://www.waltroper-aufbruch.de/Archiv/AlphatronicP2.php

He also offers the P2's BIOS ROMs for download, unfortunately his Eprom programmer can't read the P2's TMS2716 chargen ROM.

In its place he suggested to use the ITT3030's 2KB chargen ROM and he sent me the NANO 2500's chargen ROM - which turned out to be identical.

If you drop the P3 chargen into the ITT3030 driver, the ITT suddenly remembers its German provenience and starts to show Umlauts

and the shape of the characters is different, but doesn't complain otherwise.

MAME ITT3030 with original chargen ROM
[Linked Image]

MAME ITT3030 with alphatronic P3 chargen ROM
[Linked Image]

Maybe the P3's ROM could be used for an upcoming P2 driver as a "BAD DUMP" until the P2's gets dumped.

The P2 is interesting in that there are two flavours of CP/M, one that has its TPA at the common 0x0100 address, the other at 0x4300.

This guy published high quality pictures of his P2's cards:

http://petersieg.bplaced.net/?8085:Alphatronic_P1%2F2

I posted the above information on a German forum with several alphatronic owners, and one guy who has a P3 that has been expanded with the P30's coprocessor cards, posted his version of MS-DOS for the P30. It's running on an 8088 that has a 128 RAM extension card connected to it.

http://forum.classic-computing.de/index.php?page=Thread&postID=118435#post118435

This user dumped his P30's ROM

http://forum.classic-computing.de/index.php?page=Thread&threadID=10689

and a picture of a third "mystery" card that belongs in a P30.

Here are pictures of a P30 booting DOS:

http://forum.classic-computing.de/index.php?page=Thread&threadID=7785

plus a very handy guide about the correct order to plug in the P30's cards.

I/O

The IO ports appear to have been used very consistently across the alphatronic P* range:

00 SID/SOD control signal (printer port, 4800 Bd., 2 stop bits, 8 data bits)
01 - 03 * reserved
04 - 05 USART CPU (freely programmable serial port, 8251 based, 600 - 9600 Bd.)
06 - 07 * reserved
08 - 0F * reserved
10 - 17 Keyboard scan / combination interface (video)
18 - 1F * reserved
28 - 2F IEC interface cf. ftp://ftp.informatik.uni-stuttgart.de/pub/cm/alphatronic/TechnKurzinfo.pdf
30 - 4F - not used
50 - 57 Floppy
58 - 5F - not used
60 - 6F * reserved
70 - 77 - not used
78 - 79 paging for CP/M use
7A - 7F * reserved
80 - C7 - not used
C8 - CF * reserved
D0 - DF - not used
E0 - E7 * reserved
E8 - EF * reserved
F0 - FF * reserved

-------------------------

Paging

P2 U and P3 support regular CP/M use with a full 64K RAM complement.
Still, the video RAM is at 0x3000 and 0x3ffff even for these machines, and from what I've read they also use the routine present in the ROM monitor, the MOS.
That means, that in order to update the video RAM and probably other I/O the lower 16K (page 0) are constantly paged in and paged out.

This is accomplished by writing 2FH to port 0x78 in order to switch in the ROM (and assorted, see below) area and by writing 63H to port 0x78 in order to swap the full 64K RAM back in.

http://www.waltroper-aufbruch.de/Archiv/pdf/Booten_Alphatronic_P2_cpm.pdf

According to the manual,

ftp://ftp.informatik.uni-stuttgart.de/pub/cm/alphatronic/P1_P2_Systemhandbuch_Apr1982.pdf

the values written are 20H and 60H (see page 130 of the PDF), so it's probably the 7th bit that does the switching.

-----------------------

Memory maps

P1, P2 and P2S: no paging
Lower 16K for P1, P2 and P2 S

0x0000 - 0x17ff ROM monitor (MOS)
0x1800 - 0x1bff 1K RAM
0x1c00 - 0x1fff reserved
0x2000 - 0x2fff reserved, belonging to the video card's memory space (video ROM?)
0x3000 - 0x3fff actual video memory

P1
Upper 32K
0x4000 - 0x400a reserved
0x4010 - 0xc000 32K RAM

P2, P2S
Upper 48K
0x4000 - 0x400a reserved
0x4010 - 0xfff 48K RAM

P2 U
An adapter with RAM at 0x0000 and 0x3fff and the banking logic (see above) is added to the the standard 48K memory card.
16K memory card

P3, P4
0x0000 - 0x0fff ROM monitor (MOS)
0x1000 - 0x17ff free
0x1800 - 0x1bff monitor stack (RAM)
0x1c00 - 0x2fff free
0x3000 - 0x3fff video memory
0x4000 - 0xfff RAM

-----------------------

CPU

The P3's manual lists the 8085A's operating frequency as 3MHz, the sales brochure lists the system frequency as 6MHz ... nice sales spin on the 8085's halving of the frequency

-----------------------

Floppy drives

P1: one 5,25" drive, single sided, double density, 160KB, 40 tracks, 16 sectors / track, 256 bytes/sector, "according to IBM 34" (sales brochure)
P2: two 5,25" drives, single sided, double density, 160K (see above)
P2 S: two 5,25" drives, double sided, double density, 320K, 40 tracks, 16 sectors / track, 256 bytes/sector, "according to IBM 34"
P2 U: two 5,25" drives, double sided, double density, 320K, 40 tracks, 16 sectors / track, 256 bytes/sector, "according to IBM 34"
P3: two 5,25" drives, double sided, quad density, (or double track, as the sales brochure puts it), 785K,77 tracks, 5 sectors / track, 1KB/sector, 3 system tracks
P4: one 5,25" drive, double sided, quad density, 785K (see above) and one 15MB (12,5MB formatted) hard disk

P3 and P4 support data transfer from the lower spec machines:
On the P3, drive B: and on the P4 the single drive A: can access single sided disks from a P2 and the first side of the double sided disks from a P2 S and P2 U as a pseudo drive "P".

For emulation purposes, adding a third single sided DD drive to those machines would probably be the way to go.

CP/M on P2 S (48K machine without bank switching)

There is a CP/M version with its TPA at 0x4300 in order to support the OS on the simpler machine.
CP/M programs have to be adapted in order to use that setup.

A set of USCD-Pascal disks for the Alphatronics P2L has been posted. Uploads to this German forum are hosted directly there and available even without registration. But I put them on the FTP too, along with the P2's and P3's files.

http://forum.classic-computing.de/index.php?page=Thread&postID=124154#post124154

I've committed an initial skeleton driver for the P3. Works as far enough to show this message:

[Linked Image]

If anyone wants to continue working on the driver, feel free to do so.

Thanks, Duke!
I might pester you about it again soon enough

Robert

Unfortunately the keyboard controller ROM dump turned out to be bad - TeamE to the rescue, he dumped the 8049 of the first machine and the 8278 of another that I've acquired in the mean time with consistent results. Thanks!

The ROM dumps are on the FTP and here:

TA Alphatronic P3 ROM dumps (new)

alphatpx.cpp

I thing @Duke you must change in line:

121: uint8_t code = m_vram[(y * 24) + x] & 0x7f; // 24 change to 128 for position a line in the Display-RAM

a new line in the Display RAM-memory start with a step for 128 or 80h.
And the layout must like this:

3000h: # line 1
3080h: # line 2 ..
...
3B80h: # line 24
——— so is 3kB Address -Range , butter a line in real used only from 0 .... to 4F for 80 char per line.

Please the Display card must connected in the Memory MAP range from 3FF0h to 3FFEh as normal mem read/write to the physikalisches CRT-CHIP Register as io read/write in real.

Please you can modify this - thanks.

Welome @helwie44 ... who operates a site on the P2 that I've linked to before and who has worked on the SKS family machines (SKS nano, ITT 3030 and the Alphatronic P1-P4 range).

Hello and welcome helwie44, I'm not currently working on the Alphatronic machines. It's very nice to see someone who did lots of work on those machines here though.

Eventually I'll continue to work on it (if someone else isn't picking up the driver), then I'll be sure to contact you.

The range 0x3ff0 to 0x3ffe is already forwarded to the crt registers, see https://git.redump.net/mame/tree/src/mame/drivers/alphatpx.cpp#n65 (0x37f0 with mirror 0x800 so it's at 0x37f0 and 0x3ff0).

Snapshot of current state of alphatpx.cpp at https://github.com/rfka01/mame, ROMs and soft on the FTP.

p3_keyboard_mab8041a.bin looks like an alternate revision of p3_keyboard_8278.bin. However, the former is a bad dump, with D2 equal to A2 in every byte.

rfka01: I left a PR in your fork to mess with.

In a swell foop crazyc got the P3 to boot ... the exemplary disk spiele.img boots (others at ftp://ftp.informatik.uni-stuttgart.de/pub/cm/alphatronic/p3/ have issues with copy protection that might not have been transferred into the image, people have problems saving them back to disks and booting them on the real thing).

I need some help understanding the bankdev'd memory map:

Code

static ADDRESS_MAP_START( alphatp3_map, AS_PROGRAM, 8, alphatpx_state )
	AM_RANGE(0x00000, 0x017ff) AM_READ_BANK("rom") AM_WRITE_BANK("ram_0000")  
	AM_RANGE(0x01800, 0x02fff) AM_RAMBANK("ram_1800")						  
	AM_RANGE(0x03000, 0x03bff) AM_RAM AM_SHARE("vram")						  
	AM_RANGE(0x03FF0, 0x03fff) AM_DEVREADWRITE("crtc", crt5037_device, read, write) //test hw

	AM_RANGE(0x04000, 0x0ffff) AM_RAMBANK("ram_4000")
	AM_RANGE(0x10000, 0x1ffff) AM_RAMBANK("ram")
ADDRESS_MAP_END

and

Code

WRITE8_MEMBER(alphatpx_state::bank_w)
{
	m_bankdev->set_bank(BIT(data, 6));
}

Does that mean that depending on the state of bit 6 of bank_w, either "rom" or "ram_0000" is selected?

Why is the line

Code

AM_RANGE(0x10000, 0x1ffff) AM_RAMBANK("ram")

needed, as it specifies 64K-128K RAM in a strictly 64K system?

If I omit it, MAME crashes with the error

Code

-----------------------------------------------------
Exception at EIP=000000000226b37f (memory_bank::set_base(void*)+0x000f): ACCESS VIOLATION
While attempting to read memory at 0000000000000008
-----------------------------------------------------
RAX=0000000000000000 RBX=0000000020b5b8d0 RCX=0000000000000000 RDX=000000002aaf4f50
RSI=000000002aaf4f50 RDI=00000000000012b8 RBP=000000001c308240 RSP=000000001c308220
 R8=000000000001b6b3  R9=0000000000000004 R10=000000000000000f R11=000000001c308200
R12=0000000000000000 R13=0000000000000001 R14=000000001c308790 R15=0000000004dc0168
-----------------------------------------------------
Stack crawl:
  000000001c308230: 000000000226b37f (memory_bank::set_base(void*)+0x000f)
  000000001c3082c0: 0000000000b7f67e (alphatpx_state::machine_start()+0x010e)
  000000001c308310: 0000000002264bc3 (driver_device::device_start()+0x02f3)
  000000001c308420: 000000000221c4d0 (device_t::start()+0x0090)
  000000001c3084a0: 00000000022ba992 (running_machine::start_all_devices()+0x00c2)
  000000001c3085a0: 00000000022bf44f (running_machine::start()+0x085f)
  000000001c3086a0: 00000000022c0ad0 (running_machine::run(bool)+0x0140)
  000000001c30f250: 0000000000eb1493 (mame_machine_manager::execute()+0x01e3)
  000000001c30f4f0: 0000000000f22d29 (cli_frontend::start_execution(mame_machine_manager*, std::vector<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >, std::allocator<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > > > const&)+0x03f9)
  000000001c30f680: 0000000000f231a5 (cli_frontend::execute(std::vector<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >, std::allocator<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > > >&)+0x0045)
  000000001c30f6e0: 0000000000eaf52a (emulator_info::start_frontend(emu_options&, osd_interface&, std::vector<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >, std::allocator<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > > >&)+0x002a)
  000000001c30fe50: 00000000041b221d (main+0x013d)
  000000001c30ff20: 00000000004013f8 (__tmainCRTStartup+0x0248)
  000000001c30ff50: 000000000040151b (mainCRTStartup+0x001b)
  000000001c30ff80: 00007ffcc48f1fe4 (BaseThreadInitThunk+0x0014)
  000000001c30ffd0: 00007ffcc714ef91 (RtlUserThreadStart+0x0021)
Segmentation fault

How do I read the lines in machine start

Code

	membank("rom")->set_base(memregion("boot")->base());
	membank("ram_0000")->set_base(m_ram.get() + 0x0000);
	membank("ram_1800")->set_base(m_ram.get() + 0x1800);
	membank("ram_4000")->set_base(m_ram.get() + 0x4000);
	membank("ram")->set_base(m_ram.get());

Returning to the address map, can memory regions be grouped and banked in and out - the P3 swaps between 0x0000-0x3fff RAM and ROM/RAM1800/VRAM/CRTC for every access to the video memory, disk routines et al. - at the moment I think only 0x0000-0x17ff get swapped.

The bankdev device is very powerful: it maps a sliding-window view of its own address map into the source address map.

The key is here:

MCFG_ADDRESS_MAP_BANK_STRIDE(0x10000)

That means that the number you pass to set_bank is multiplied by that to get where in the bankdev's address map is visible in the main address map.

So Z80 address 0 is 0 in the bankdev's map when set_bank(0), and Z80 address 0 is 0x10000 in the bankdev's map when set_bank(1). MAME crashes when you omit the RAM because it's not an additional 64K, it's the base 64K for CP/M mode where 100% of the 64K is usable RAM.

The bonus of all of this over conventional banking in MAME is that it's much faster when the bank view changes frequently, because it's only updating the base address of the sliding window. The "new" 2014 Apple II driver was about 3 times faster simply because I changed it to use bankdev instead of the old-style banking.

Also, these lines

Code

	membank("rom")->set_base(memregion("boot")->base());
	membank("ram_0000")->set_base(m_ram.get() + 0x0000);
	membank("ram_1800")->set_base(m_ram.get() + 0x1800);
	membank("ram_4000")->set_base(m_ram.get() + 0x4000);
	membank("ram")->set_base(m_ram.get());

...map the various RAM views in bank 0 to their correct places in the full 64K in bank 1.

I did some of this in a new PR but there are still issues with the way the rom is mapped. MBasic for example tries to do CP/M syscalls (CALL 5) while the rom is mapped in resulting in a branch to the wrong place.

Adding 1kb of separate ram at 0x1800 that is implied by the memmap on the first page (there's also 2 512 byte sram chips on the cpu board) fixes the above problem. The main problems now is the keyboard missing shift key and doubling key presses.

Thanks!
We've put a call out for help for more dumps of the keyboard controller, since one of mine is obviously flaky, the 8041 gives inconsistent dumps all the way, so we're stuck with the 8278 dump for the moment.

I'll post a table helwie sent me that might help demystify the keyboard addresses.

Robert

This is helwie44's comparison chart between the ITT3030's and the Alphatronic's keyboard

https://mega.nz/#!OBg3SKhK!qdSM_MxRl6ml5buVcI9xvU9f2Jb-zBewILcv6EZw_1c

I grabbed the head of your tree and pushed it. It was just diverging too much making it hard to work on.

Robert, do the "inconsistent dumps" of the 8041 all have bad readings on D2? If not, it should be possible to make a good dump out of them by piecing a couple together (and using the 8278 dump as a reference).

I've put a set of the bad dumps of the 8041 from both TeamE and myself on the FTP.

Thank you for many changes so that the driver goes ahead. In this source version - the translation is aborted with an error.
therefore, I have locally exchanged two source lines back with me. This is the translation has been done.

Quote

Part alphatpx.cpp
// MCFG_ADDRESS_MAP_BANK_DATA_WIDTH(8) // is not in scope ERROR
// MCFG_ADDRESS_MAP_BANK_ADDR_WIDTH(18) // the same

MCFG_ADDRESS_MAP_BANK_DATABUS_WIDTH(8) //from before version helwie44 change 07.12. 20:00
MCFG_ADDRESS_MAP_BANK_ADDRBUS_WIDTH(18) // the same - now compile und run

The SHIFT function is obviously visible via the 0xCy function code via the Excel table. Thanks for good work!

The main problem with the double character (with a keystroke) is opaque. In 8085 debug mode, the MAME of the 8278 chip on port 0x11 will always return the first read from the 0x10 dataport (1st character is ok), but then the status port 0x11 will already supply a character as ready. And the data port 0x10 provides an identical character.
Could it possibly be a wrong timing in the 8278 chip emulation? From the documentation of the 8278, the internal scan time is about 10 ms !!?
Does anyone have deeper information - about this error behavior?

Using the BP-1400 programmer LN procured for me, I dumped the 8041 that was yielding iffy reads for both TeamE and me, and they're turning out identical every time now, plus they're identical with the 8278 from the other machine.

https://mega.nz/#!uZ4VzJaL!NuFOf8xXVbWZA_jpE1kpudqupRkViXz6aIIiy3Bckk0

After examining the various dumps, I reconsidered my earlier judgment. Of course it wasn't just D2 that would be bad in the first dump; bytes were getting swapped across A2, too. I don't think it really helps to include two identical dumps as separate BIOS versions, though...

If you can add the second chargen in a way that allows easy switching (and therefore switching between the two machines that differ in their card sets, even though they share the same BIOS and keyboard ROMs) it would be great.

If they were marketed as two different machines, just make two system drivers. If the charset was an option, just add both and add a configure switch to switch between the two. In your screen drawing routine you then just take the characters from either ROM.

"Machine 1" as it's called in the current source is actually a later version of the P3. It has the PSU and voltage regulator cards, 64K DRAM card, 8085 CPU card, floppy controller card, video/keyboard interface card with the later char ROM

"Machine 2" has the earlier char ROM and the DRAM split across a 48K and a 16K card.

The keyboard ROMs contain the same code but come from different ICs (8278 vs. 8041).

So they're neither marketed as two different machines nor is the newer char ROM an add-on option - hence I thought switching the complete sets as "BIOS" was appropriate.

Both my Alphatronic P2's cases are cracked, so I'll link you to a more esthetically pleasing example:

https://www.1000bit.it/scheda.asp?id=286

helwie44's site I linked to earlier is all about the P2.

The P2's are evolutionary predecessors to the P3 with the boards and the keyboard in a single case. Mine are "straight" P2's, no P2S (2x320K disks) or P2U (2x320K disks, 64K RAM), so they've just got 48K RAM, no bankswitching involved, and 2x160K floppy disk drives, 40 tracks, 16 sectors/track, 256 bytes/sector.

Here are photos, ROM dumps and disk images for the P2 (also on the FTP).

I've redacted my PR for the P3, reducing superfluous ROM loading and added the dumps for my two P2's.
It's nice to see how the machines evolved, from concentrating RAM on one board instead of three to editing the font from using quaint serifs like on the "T" of RESET to a non-serif font.
That later char ROM crops up again on the early P3 then.

[Linked Image]

With my current pull request for the Alphatronics, I've added sound - port 0x12 was always present on the error log.
The beeper is working well, I've adjusted the frequency by ear, and if you boot the file wordstar170.imd from this
archive, things look fine apart from the case of the doubled characters from the keyboard.

I will get the ROM labels for the three machines not dumped by myself, so in preparation for that I've split the concatenated ROMs to match the others.
This has uncovered TA's mix-and match approach for the three ROMs via the checksums

If you boot the other disk image, sys3-25.imd, the beep is much lower in pitch, and you get treated to non-stop white noise.

The P2's 8085 unfortunately runs into a halt after showing the RESET message.

P30's 8088 board seems to be communicating via ports 0x08 and 0xff.

crazyc, if you could please give us another nudge in the right direction, I'd be most grateful

Hello mates (especially Helmut and Robert),

I'd want to join you. Two years ago I tried to make a P1/P2 emulator by myself, but I had to strip i down due to time constraints, and it was my final project as a simple 8085 emulator.

Originally Posted by "rfka01"

The P2's 8085 unfortunately runs into a halt after showing the RESET message.

When you mean a halt you mean the instruction HLT? If it is, then it is waiting an INT, maybe some kind of ack signal froma another card module. Decompiling the ROM may give some kind of clue.

Whenever I had time I will send you both my MOS and char ROMs (Helmut taught me to extract them, but I lost the copies on a HDD malfunction a year ago). I think my MOS was same as Helmut's, but my char ROM is Spanish.
If you are interested, I think where you could find a US version ROMs, but it will require some research.

See you,
Jaume

Welcome, Jaume!

Yes, the P2 stops executing on a HLT instruction.

MAME has a built in debugger (add -debug on your command line) that you should try

The keyboard controller was not getting enough timeslices to clear the queue status before the cpu checked it after reading a key.

Thanks! I wouldn't even have guessed where to look.
In the meantime helwie is sussing out the keyboard matrix, I dumped and revitalised my P30 and will post about it tomorrow, and jlopezm is attempting to dump a complete set from his unique Spanish machine.

Robert

Many thanks to the ingenious developer and tinkerer @crazyc.

The timing with the change of the double button is done.

The SHIFT key can now be held and a character switched correctly.
The F1 to F6 buttons are ok. ESC exactly ok!

Now I have reworked the MATRIX. The CTRL function is missing at the moment.
I have sent the source @rfka01 for verification - the alphatp3 works great for me!

We just do not have a CURSOR in the emulation here.
I think there might be something missing on the display chip connections.
The Registe MAP is in the area 03FF0-03FFFh only as a write option.
The MOS software may use the registers for the cursor positions, red and write mus have a way.

helwie44's spent countless hours on mapping the keyboard. I'm especially surprised that he managed to find an equivalent for the P3's "SM" (Schreibmaschine) key. It's mapped to F11 and controls the shift mode of the keyboard.
I got a P30 today, a P3 with a graphics extension and a 8088 coprocessor card with its dedicated 128K of RAM. The 8088 card ROM and the 8085 MOS were a direct match of what we had from another German user, I added the correct ROM label for the 8088 ROM, verified the char ROM and dumped the keyboard controller.

[Linked Image]

This picture was taken before I moved the rightmost card one slot left, this got it booting. The rightmost slot carries additional signals for I/O cards.

The P30 is using a different floppy controller card than the P3's built around a WD2797

[Linked Image]

The three extra cards are tied together with ribbon cable:

[Linked Image]

They're the 8088 CPU card, 128K RAM card and a 32K Graphics extension that provides 640x288 pixels in 8 colours.

[Linked Image]

The heatsink hides a memory controller

[Linked Image]

This is the graphics extension:

[Linked Image]

The files are already on the FTP and you can find them here.

Unfortunately the current state of emulation doesn't like the addition of the new keyboard controller - it prints "w#" and dies

If you boot a disk on the 8085 side, it again dies after printing "w" you need a hard reset to get it out of that state.

[Linked Image]

Missing cursor

Quote

We just do not have a CURSOR in the emulation here. I think there might be something missing on the display chip connections.
The Registe MAP is in the area 03FF0-03FFFh only as a write option.

Here I have the original development documents from sks to the DISPLAY CONTROLLER for the KISS PC. A slight revision was made by TA for the alphatronic P2 series. And also used for the TA P3 / P30 systems.
Hardware (memory usage) and the software ratings are always almost identical.

Display schematic / software parameters

In my revision of the MATRIX I have now the Ctrl function available.
Via Esc key and another key, a Ctrl code is sent. That was exactly the same with TA. From the cp / m operation, this kind works properly.

The cursor on 6845 systems is the responsibility of the draw callback; the 6845 itself just tells you where it is, not what style it is.

Quote

The cursor on 6845 systems

The Alphatronic P2's use crt5027, P3 and P30 crt5037, i.e. TMS9927 ... does it work with them the same way? I couldn't find an example where a driver that uses these chips explicitly sets a cursor.

helwie44 mentioned that on a P3 (which uses 80 track floppies) you can insert a P2 disk (40 tracks, single sided) or P2S/P2U (40 tracks, double sided), and as long as your files are on the first side of the floppy, you can import these via the "Pseudo drive" P:
MAME lets me mount the image, but I get a BDOS error ... is this the same double stepping problem as with 360K disks in 1.2M drives on PC drivers?

The 8085's RST lines are used in the Alphatronics, 7.5 connects to the keyboard system, 6.5 is vsync ("Bildimpuls-Lücke") and 5.5 hsync ("Zeilenimpuls-Lücke"). According to helwie44 connecting these will help the P2 driver continue from its current waiting (HLT) state.
For the vsync signal, the source contains the line

Code

MCFG_TMS9927_VSYN_CALLBACK(INPUTLINE("maincpu", I8085_RST65_LINE)) MCFG_DEVCB_XOR(1)

Is this all that's needed or is there additional code required?

Currently, the vram is setup as

Code

AM_RANGE(0x03000, 0x03bff) AM_WRITEONLY AM_SHARE("vram")

. helwie44 says, the vram should be readable from the main cpu as well as from the display controller. Would changing to AM_RAM AM_SHARE do the trick?

In order:

- I'm unfamiliar with how the cursor works on the 9927.
- This is the same double-stepping problem. You cannot read discs in MAME on a drive that isn't an exact geometry match, period.
- The 9927 implementation in MAME doesn't have an HSYNC callback or output. One will need to be added. VSync is fine as-is.
- The VRAM is fine as-is, I think. It looks at a glance like both the CPU and display controller can access it. If the CPU really can write it, then yes, AM_RAM AM_SHARE works.

crt5027 iirc is also used on the xerox notetaker, and it needs the vblank, hblank and odd/even pins to be emulated to work properly. Currently we only do vblank (and maybe hblank), which causes major issues since the odd/even field pin is used as an interrupt source on the notetaker.

The Odd/even pin when in interlaced mode stays active for one field and inactive for the next field (and each field is only displaying the odd or even lines).
In non-interlaced mode, the odd/even pin is the lsb of the scanline number, so it inverts every scanline.
I guess technically the odd/even pin is ALWAYS the lsb of the scanline number, just the scanline is incremented by 2 in interlaced mode, and 1 in non-interlaced mode.

The notetaker uses the interlaced mode.

LN

Just wanted to say thanks to Carl ... a CURSORY glance had shown that he had been busy

@LN ... it would be great if you could as HSYNC to the graphics chip.

Carl's and AJR's contributions have advanced the state of the Alphatronics emulation in wide leaps ... I will post disk images tomorrow that match the drivers and may help.

The P2 series now shows signs of life after the provision of a HSYNC signal from the TMS9927 driver.
All you need is a little patience, as it takes a while for the MOS prompt to show up.

[Linked Image]

From here you can boot into two regions on the disk using the B (in the case of this disk a BASIC dialect) and B1 (here shown with a disk utility) commands.

[Linked Image]

A speciality of the TA P2 and P2S is the existence of a CP/M with a TPA at 0x4300 that uses no bankswitching and keeps the MOS ROM below.

[Linked Image]

The P2U has the same bank switching logic as the P3 and can boot a "full" 64K CP/M

[Linked Image]

In MAME, the P2 varieties and P3 share most of their code, so at the moment even the lowly P2 can boot the 64K CP/M.

The Alphatronics' cursor moves back to line 1 (and then down the screen again) if you go beyond line 24 of the text screen.

[Linked Image]

So at the moment the next challenges are (and help is again most welcome)

* fix the cursor movement
* give the P2 line its proper video chip, the 5527 instead of the 5537
* seperate the P2 models better (single sided vs. double sided, remove bank switching in P2 and P2S but keep for P2U)
* check why video using the HSYNC is slowing down the system
* fix data exchange between P3 and P2

I thought I could get around the double stepping problem by allowing the P3 to switch to a DSDD drive, but even then I get a BDOS error if I try to access P2 disks via the pseudo drive P:

Quote

check why video using the HSYNC is slowing down the system

Unfortunately this is practically unavoidable. The HSYN output has to turn on and then off at a set period during every scanline, including during the vertical sync and blanking period. Currently this timer is disabled when the HSYN callback isn't configured, since many systems use it only to drive the monitor or not at all (since the actual device also generates a composite sync output).

I rather doubt that VSYN is really meant to be inverted. The TMS9927's VSYN output is active high, and the 8085 RST 6.5 input is also triggered at a high level both on actual hardware and in MAME (which generally treats IRQ lines as active high, even though they happen to be active low on actual hardware more often than not).

And the slowdown in the emulation may be due to the wrongly inverted VSYN.

After perusing the Notetaker schematics, I think P2 might be doing something similar to what it does: the video board inverts VSYN to buffer it onto the bus, and the CPU board inverts it yet again to turn it into an active-high interrupt input (though the Notetaker I/O CPU receives it indirectly through a 8259 PIC).

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]

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:

[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.

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/

[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.

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:

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*')

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.

Thanks Vas and Duke for navigating me through hitherto uncharted territory (for me

)

crazyc has laid the groundwork for the emulation of the P30's 8088 card ... thanks once again!

[Linked Image]

A guy on the German VzEkC forum measured the output of the graphics extension card to the 9pin D-sub connector on the back of the machine and found TTL level R-G-B, 50Hz VSync "with a negative pulse" and 15.6kHz HSync.

He describes that in order to use the bootable MS-DOS disk he had to rename the config.sys file so the driver disdeu.sys wouldn't be loaded as that would cause the display to scroll and blank.

Could it be that the graphics extension is only meant to serve the monitor on the digital output and disdeu.sys is a monitor switcher?

There's a spurious "w" character generated on reset of the P30 ... dunno where that's from. I hope the firmware dumps are OK.

There's two monitors? There's no second crtc so it must use the same timing as the first one. Disdeu.sys is probably for localization (deu for german) and it forces output to the extension as before it's loaded the displayed text is passed to the 8085 for output to the first monitor. If you look at the disk image you can see remnants of files like diseng.sys.

Here are the connectors for the P30

[Linked Image]

The P3 on the other hand is missing the 9 pin D-sub below the Cinch connector.

[Linked Image]

I had forgotten to take pictures of the connectors when I got the machine.

Edith says: I don't have the digital monitor to go with the graphics extension, just the composite one.

Not loading disdeu.sys keeps the output on the first monitor, but the keyboard is not working on the P30.

The P30 keyboard controller program isn't quite compatible with the 8278. If I ignore the keyboard clock it misbehaves in the same way as the 8278 so I added a hack which works even though I don't think it's correct.

Nice! The keyboard controller on the P30 is a NEC D8741AD. I'll ask in the German forum for software to try in the P30 emulation.
Is it possible to allow split screen for the graphics extension like on the Rainbow driver?

Originally Posted by rfka01

NEC D8741AD

If possible, we should get a dump of that MCU.

LN

Originally Posted by rfka01

Nice! The keyboard controller on the P30 is a NEC D8741AD. I'll ask in the German forum for software to try in the P30 emulation.
Is it possible to allow split screen for the graphics extension like on the Rainbow driver?

Not without some difficulty as there's not really any simple way to bind two screens to one crtc. Note the graphics extension still doesn't work properly, that shot is with disdeu.sys disabled.

Originally Posted by Lord Nightmare

If possible, we should get a dump of that MCU.

LN

It's dumped and emulated. Also, the P3 driver has a dump of the 8278 (which is an 8041 with a standard program) so if there are any other drivers that use an 8278 but lack a dump of it, that one should be just able to be dropped in.

helwie44 pointed out that the latest changes seem to have affected cursor behaviour in the P2 line of drivers. I'm still hoping to find software that accesses the graphics extension on the P30.

[Linked Image]

There's definitely support for both mono and color in the graphics extension driver in the 8088 rom. Port 0xfb00-f looks like a 16 color palette which would require 4 23K bit planes plus 4x12K for the font ram. There must have been a 80K+ vram extension which your machine doesn't appear to have had (possibly it was never built?).

P2U - CURSOR - position ok

Hello, thank you for the work of the MAME alphatronic of the Px systems.
The small CURSOR error I found absolutely a trifle.

Here the modify cursor.contains( ..)

Code

// draw 12 lines of the character
   bool cursoren = cursor.contains(x * 8, y * 12);

In the current source code, in line 884 simply change the variable "vramy * 12" to "y * 12".
Already the P2U CURSOR is in the right line.
I think that's easy to take into account in the next revision.

helwie: Carl already fixed that

helwie's noticed that the P30's clock is running about twice as fast as it should be.

[Linked Image]

I'm translating his notes on banking for the Alphatronics series, and he's preparing to introduce a descendant of those machines, the Hell DS2069, a typesetting terminal for the Hell printing machines.

The pit drives the clock and I just set the frequency to 1Mhz which is wrong. It's likely 15Mhz with some unknown divider.

The changes don't seem to affect the internal clock.

[Linked Image]

I've entered the "real" time after querying internal time.

helwie has raided his archives and found the assembler source for a clock driver for the P30 that sets the PIT specifically to 100kHz

He's also included the schematics for a SASI adapter to connect an early Syquest drive to the Alphatronics. DOS on the P30 is supposed to contain the driver that is needed, and there are assembler sources to modify CP/M.
I've uploaded his stuff to the FTP.

TEST 100kHz CLOCK to P30 MSDOS -MAME

Many thanks to all wonderful developers of these historical computers - which were originally developed from the "developer-forge" sks "Steinmetz-Krischke-Systems" from Karlsruhe.

Basis was the MC80 BUS with the systems sks "KISS", then TA Alphatoronic P1 / P2, P3, P30 to company HELL, Kiel DS2069 and others like sks nano 2500 and the ITT3030.

The first test result:
[Linked Image]

test 512 kB RAM and ckockfreq. 100 kHz

My test to the P30 MSDOS with the clock to my old documents (thanks of rfka01 for the upload) is apparently with the CLOCKDRIVER on 100 kHz perfect results.
Whether this other side effects, I have not yet tested.
Incidentally, I have for me in the. Cpp code simply set to a 8088 memory of 512 Kb.

I hope an active (hardware P30 machine, Germany) user ("netmercer" FORUM Germany) could bring us some MSDOS 2.0 programs to the TA MSDOS format and make ourselves available.

You think this looks like the bastard child of a Siemens machine, the ITT3030 and the NCC1701? HELL, you're right ... and it's hell of Linotype-Hell fame.

They took the TA P2U as a basis for their typesetting system, put it in a late 70s fugly plastic case, combined it with a stock keyboard from their mother company and mixed and matched with other components from the SKS grab bag. The disk drives look familiar, as does the CPU card, although the christmas sticker is a nice touch

Lots of extra keys on the keyboard which is appropriate for a typesetting machine. The keyboards uses a different connection than the P2 series, it needs is read via the INT7.5

[Linked Image]

helwie44 was with the Hell company, and he's sent me his files which I've put on the FTP but can also be found here.

What really sets the DS2069 apart from the Alphatronic line is that it's missing a character generator. The usual Video RAM is stacked four banks deep, and the machine initially comes blank, you have to blindly type in "B" to boot and then load a character set using the "LF" command. The blank lines are a feature, the characters are 16x16 pixels.

[Linked Image]

This mechanism allows to use four character sets concurrently.

[Linked Image]

The archive contains the MOS and keyboard proms and some disks as well as the photos of the cards and lots of documentation.

Background for the star - label - EPROM from the DS2069 CPU card

Thanks for the careful collection of the data view device of the company Dr. Ing. Ing. Rudolf HELL, Kiel Germany. The company name does not mean in German meaning as in English.
I also made the EPROM with the star label an adaptation for the company, in order to first use the BASF 6108 floppy disk drives with the successor floppy disk drives for PANASONIC JU 455-5. Today I still jut myself 455-5 drives in the DS 2069 or in an Alphatronc P2U.
In MAME / MESS, it would be welcome to implement help for an INT 7.5 (8085), for example, only in the alphatronic P2 / or P2U. The keyboard actually processes in the DS2069,
only via the interrupt 7.5.

Helwie44