Previous Thread
Next Thread
Print Thread
Page 38 of 56 1 2 36 37 38 39 40 55 56
Al Kossow #107450 09/27/16 08:50 PM
Joined: Mar 2006
Posts: 1,080
Likes: 7
L
Very Senior Member
Very Senior Member
L Offline
Joined: Mar 2006
Posts: 1,080
Likes: 7
Originally Posted by Al Kossow
This makes me want to poke a the quad qbus 7220 board that came in the Calcomp branded Terak that I have again. Problem is I have no software for it.

I have some terak-branded disks i dumped a long while ago from a box I found at university, but I think they hold word processing stuff for the exidy sorceror disk drive expansion box, not terak stuff. Just reused 8" disks.

LN


"When life gives you zombies... *CHA-CHIK!* ...you make zombie-ade!"
rfka01 #107657 10/17/16 06:53 PM
Joined: Apr 2012
Posts: 193
B
Senior Member
Senior Member
B Offline
Joined: Apr 2012
Posts: 193
New findings:
- the "status register" test (#4) pokes the GDC command port $57 circa 28 times with 0x22 (WDAT ?), then queries the status port $56. It then expects a FIFO_FULL response (instead of EMPTY..as it is now).
Is it the flags or the timing?

- later tests of the GDC diagnostic disc often invoke RDAT with mod = 02 (unimplemented ?).

On the positive side, the scroll test (#2) looks good, so we are at 23 % now ;-)

[Linked Image from dl.dropboxusercontent.com]

Last edited by Bavarese; 10/17/16 07:08 PM.
rfka01 #107658 10/17/16 07:22 PM
Joined: Jan 2012
Posts: 892
Likes: 17
C
Senior Member
Senior Member
C Offline
Joined: Jan 2012
Posts: 892
Likes: 17
WDAT occurs instantly so the FIFO will never fill. It should probably be converted to an execute device so each operation can take the proper number of cycles.

RDAT with a mod is undocumented and doesn't really make much sense so without testing on real hardware we can't know what to do with it.

rfka01 #107669 10/18/16 04:28 PM
Joined: Apr 2012
Posts: 193
B
Senior Member
Senior Member
B Offline
Joined: Apr 2012
Posts: 193
Isn't RDAT documented on page 216 of the Programmers Reference from June 1984?

On another note, vector and hires modes show something - although parameters like direction (DIR) and X/Y (of lines and arcs) seem to be oddly 'reversed'. crazy

I have to override 'm_bitmap_mod' in UPD7220.CPP, otherwise figures never appear. WDAT 0x22 (see above) frequently sets RMW mode to 2, which zaps all bits. Sure, i haven't fully grasped how the extra hardware and the GDC interact..

Mastermind intro. Circles are OK. Arc over text should appear rotated 180 degrees to right (adjacent to character w)...
[Linked Image from dl.dropboxusercontent.com] [Linked Image from dl.dropboxusercontent.com]

[Linked Image from dl.dropboxusercontent.com] [Linked Image from dl.dropboxusercontent.com] Graphics Demo. Text barely readable (X axis...), lines have wrong direction

[Linked Image from dl.dropboxusercontent.com]
(Solitaire, hires, with vector mode)

Last edited by Bavarese; 10/18/16 05:22 PM.
Bavarese #107670 10/18/16 06:06 PM
Joined: Jan 2012
Posts: 892
Likes: 17
C
Senior Member
Senior Member
C Offline
Joined: Jan 2012
Posts: 892
Likes: 17
Originally Posted by Bavarese
Isn't RDAT documented on page 216 of the Programmers Reference from June 1984?

I hadn't seen that doc just the nec doc which says nothing about the mod and the Intel clone doc which says mod must be 0.

rfka01 #107768 10/28/16 05:11 PM
Joined: Apr 2012
Posts: 193
B
Senior Member
Senior Member
B Offline
Joined: Apr 2012
Posts: 193
Sorry, i didnt want to be nosey.

A new pull request is available on Github (Enhance DEC Rainbow 100 Option Graphics #1589).

It seems i am a bit at a dead end with the NEC GDC.

Perhaps someone more knowledgeable could have a look at vector mode and the odd FIG parameters - see section BUGS in #1589

Code
+Interaction of Upd7220 and Rainbow.cpp:
+- FIG directions / params appear to be odd (lines go 45 degrees up or down instead of straight dir.),
+- RDAT with MOD 2 is unimplemented. WDAT appears to set "m_bitmap_mod" wrongly ("2" means all pixels will be reset)
...
Text looks funny too (see screenshots above) smile

Several assembly snippets and freeware games are here (ASM in folder EX32)

Last edited by Bavarese; 10/28/16 05:28 PM.
Bavarese #107769 10/28/16 07:04 PM
Joined: Jan 2012
Posts: 892
Likes: 17
C
Senior Member
Senior Member
C Offline
Joined: Jan 2012
Posts: 892
Likes: 17
Originally Posted by Bavarese
Sorry, i didnt want to be nosey.
If this is directed at me, I was just laying out the docs for why RDAT is like it is. It might be that the bytes are supposed to be cleared, set or complemented as they are read out but nothing says that anywhere.

Bavarese #107784 10/31/16 10:08 PM
Joined: May 2012
Posts: 572
Likes: 13
S
Senior Member
Senior Member
S Offline
Joined: May 2012
Posts: 572
Likes: 13
Originally Posted by Bavarese
The self test is bypassed by unmapping the MPSC and activating the handlers when everything is normal.

Now i can send data from the Rainbow to a Putty terminal. There is no transmission in the other direction, as far as i can see...


I've changed z80dart_channel::receive_data to print fifo depth and apparently, the rx register is not being read -- maybe interrupt service routine does not run?

(this is from error.log when raibow is connected to remote loopback i.e. TCP echo service)
Code
[:upd7201:cha] Z80DART ":upd7201" Channel A : Receive Data Byte '2f' (fifo -1)
[:upd7201:cha] Z80DART ":upd7201" Channel A : Receive Data Byte '2f' (fifo 0)
[:upd7201:cha] Z80DART ":upd7201" Channel A : Receive Data Byte '2f' (fifo 1)
[:upd7201:cha] Z80DART ":upd7201" Channel A : Receive Data Byte '2f' (fifo 2)
[:upd7201:cha] Z80DART ":upd7201" Channel A : Receive Data Byte '2f' (fifo 2)
[:upd7201:cha] Z80DART ":upd7201" Channel A : Receive Data Byte '2f' (fifo 2)
[:upd7201:cha] Z80DART ":upd7201" Channel A : Receive Data Byte '2f' (fifo 2)
[:upd7201:cha] Z80DART ":upd7201" Channel A : Receive Data Byte '2f' (fifo 2)
<...>

rfka01 #107800 11/01/16 07:36 PM
Joined: May 2012
Posts: 572
Likes: 13
S
Senior Member
Senior Member
S Offline
Joined: May 2012
Posts: 572
Likes: 13
I've moved m_mpsc->m1_r(); into if() clause like so
Code
    if (m_mpsc_irq == 0) {
        lower_8088_irq(IRQ_COMM_PTR_INTR_L);
        m_mpsc->m1_r();
    } else
        raise_8088_irq(IRQ_COMM_PTR_INTR_L);

and rx now works (f.e. from a TCP chargen service) but terminal is still broken -- it starts autorepeating first character you press.

rfka01 #107807 11/03/16 01:19 PM
Joined: Apr 2012
Posts: 193
B
Senior Member
Senior Member
B Offline
Joined: Apr 2012
Posts: 193
Communication appears to work with 9600 baud, 8,N,1, (and XON/OFF) in both directions - for a short time.

After a few hundred (?) characters, sending from the Rainbow to Putty stops (in terminal mode T). A handshake problem?

Must admit i haven't checked out Edstrom's recent changes...

It would be nice if other bitrates than 9600 were possible. I heard the VT100 terminal emu works best at 4800 bps (given the slow main CPU, clocked at 4,81 Mhz).

Last edited by Bavarese; 11/03/16 01:58 PM.
Page 38 of 56 1 2 36 37 38 39 40 55 56

Link Copied to Clipboard
Who's Online Now
1 members (Heihachi_73), 111 guests, and 4 robots.
Key: Admin, Global Mod, Mod
ShoutChat
Comment Guidelines: Do post respectful and insightful comments. Don't flame, hate, spam.
Forum Statistics
Forums9
Topics9,354
Posts122,409
Members5,082
Most Online1,283
Dec 21st, 2022
Our Sponsor
These forums are sponsored by Superior Solitaire, an ad-free card game collection for macOS and iOS. Download it today!

Superior Solitaire
Powered by UBB.threads™ PHP Forum Software 8.0.0