Previous Thread
Next Thread
Print Thread
Page 8 of 8 1 2 3 4 5 6 7 8
Joined: Mar 2006
Posts: 1,072
Likes: 5
L
Very Senior Member
Offline
Very Senior Member
L
Joined: Mar 2006
Posts: 1,072
Likes: 5
I'm wondering if the cycle timing tables being wrong for the upd7810 and upd780x is causing some of the columns to be offset improperly in the printouts.
I have a local patch which partially fixes this, but I never made my way completely through the upd7810 databook to fix all the timing mistakes in the tables.

There's a LOT of mistakes!

LN


"When life gives you zombies... *CHA-CHIK!* ...you make zombie-ade!"
Joined: Feb 2014
Posts: 816
Likes: 30
G
Senior Member
OP Online Content
Senior Member
G
Joined: Feb 2014
Posts: 816
Likes: 30
Hi LN,

Yes, there's a bunch of cycle counts that aren't exact. I think that it's probably the PTS sensor that's the problem as the cpu runs much faster than the mechanical movement.
Anything's possible, I won't rule anything out 8-)


I keep having trouble with the mx80 and the alignment. I've got the PTS multiplier value set to 1:1 and that seems to fix the graphics, and mess up the text. If I set to 1:2 that fixes the text and messes up the graphics.


Graphic printout with 1:2 (clearly seems to be missing in between columns) at 120x72

[Linked Image from i.imgur.com]



Graphic printout with 1:1 (120x72) 120dpi horizontally is the mx80 limit. This looks okay without glitches.
[Linked Image from i.imgur.com]

Joined: Mar 2006
Posts: 1,072
Likes: 5
L
Very Senior Member
Offline
Very Senior Member
L
Joined: Mar 2006
Posts: 1,072
Likes: 5
I'm up to EQAW (in alphabetical order) in the upd7810 databook, fixing the timings in upd7810_table.cpp. I haven't migrated all of these fixes to the upd7803 and 7807 though, although some of them are obviously also wrong there.


"When life gives you zombies... *CHA-CHIK!* ...you make zombie-ade!"
Joined: Mar 2006
Posts: 1,072
Likes: 5
L
Very Senior Member
Offline
Very Senior Member
L
Joined: Mar 2006
Posts: 1,072
Likes: 5
Up to MUL now.
I found 2 bugs in the upd7810_table.cpp file while fixing cycle timings:
1. The first few prefix 40 opcodes are calling the 1-byte &upd7810_device::illegal handler instead of the 2-byte &upd7810_device::illegal2 handler, I don't know what sort of havoc this would cause since it only affects illegal opcodes. Because the opcodes have a prefix byte, they are 2 bytes long, so it should (if I'm understanding this right) call the illegal2 handler.
2. The more serious issue is a probable bug with the prefix 4D opcodes MOV_TXB_A, MOV_TM0_A, MOV_TM1_A, and MOV_ZCM_A which I'm pretty sure (based on the upd7810 instruction set databook) are in the wrong order in the table, causing the wrong opcodes to execute!
EDIT: scratch #2, the documentation conflicts with itself; I suspect the current order of things are correct since otherwise I suspect stuff would work much worse than it already does, if it has to do with serial communications and zero cross timing. Golden Child, correct me if I'm completely wrong here.

LN

Last edited by Lord Nightmare; 05/18/22 06:18 AM.

"When life gives you zombies... *CHA-CHIK!* ...you make zombie-ade!"
1 member likes this: Golden Child
Joined: Feb 2004
Posts: 2,366
Likes: 81
Very Senior Member
Offline
Very Senior Member
Joined: Feb 2004
Posts: 2,366
Likes: 81
Originally Posted by Lord Nightmare
2. The more serious issue is a probable bug with the prefix 4D opcodes MOV_TXB_A, MOV_TM0_A, MOV_TM1_A, and MOV_ZCM_A which I'm pretty sure (based on the upd7810 instruction set databook) are in the wrong order in the table, causing the wrong opcodes to execute!
I think you’re wrong. The SFR codes are in a table on page 21: https://www.cpcwiki.eu/imgs/4/4b/UPD78C11A_Datasheet.pdf
  • TXB = 011000
  • TM0 = 011010
  • TM1 = 011011


This matches the code in MAME.

Joined: Mar 2006
Posts: 1,072
Likes: 5
L
Very Senior Member
Offline
Very Senior Member
L
Joined: Mar 2006
Posts: 1,072
Likes: 5
Vas, I just figured that out as well, the upd78C10 document conflicts with itself; the diagram on page 93 (11-2 document page) matches what MAME does, while the documentation of the MOV opcode itself shows things the other way, which I'm assuming is just another documentation error like the SSPD thing.
Golden Child might be able to chime in since the printers they're working with probably do use those opcodes.


"When life gives you zombies... *CHA-CHIK!* ...you make zombie-ade!"
Joined: Feb 2014
Posts: 816
Likes: 30
G
Senior Member
OP Online Content
Senior Member
G
Joined: Feb 2014
Posts: 816
Likes: 30
I don't know if I can offer any insight on that particular thing.

I was going great on the RX80 and it was all pretty much working except for going off into the weeds and running the carriage completely off to the right. After resetting it, it would work just fine.


I started looking at EOM as a possibility and the datasheet says in figure 6-4 "If LV0 level inversion is enabled and either set LV0 or reset LV0 are enabled, the set or reset will override the inversion. Inversion will only work with LRE1 = 0 and LRE0 = 0. The same concept is true for LV1".

Now if I modify the void upd7810_device::upd7810_write_EOM()

to implement that, it *really* doesn't work...and they also give a diagram at 6-2 of the output control circuit showing LRE0 and LRE1 connecting to the S and R of the Master/Slave FF.

Joined: Mar 2006
Posts: 1,072
Likes: 5
L
Very Senior Member
Offline
Very Senior Member
L
Joined: Mar 2006
Posts: 1,072
Likes: 5
I figured out the difference between illegal and illegal2 handlers: the logerror print message for the former prints 1 byte for opcode, and the latter prints 2. This means the mistake in the prefix 40 table was effectively completely harmless, just making some error messages in MAME slightly wrong.


"When life gives you zombies... *CHA-CHIK!* ...you make zombie-ade!"
Page 8 of 8 1 2 3 4 5 6 7 8

Link Copied to Clipboard
Who's Online Now
0 members (), 20 guests, and 2 robots.
Key: Admin, Global Mod, Mod
ShoutChat
Comment Guidelines: Do post respectful and insightful comments. Don't flame, hate, spam.
Forum Statistics
Forums9
Topics9,085
Posts119,077
Members5,014
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