Previous Thread
Next Thread
Print Thread
Page 2 of 5 1 2 3 4 5
Joined: Feb 2014
Posts: 852
Likes: 48
G
Senior Member
OP Online Content
Senior Member
G
Joined: Feb 2014
Posts: 852
Likes: 48
There's some very strange addressing of the rom occurring. It doesn't seem to count in sequence properly.


If I put some printfs in the TMS4800 the addresses don't count up neatly.
I would expect it to be from 0 to F in sequence.

Code
TMS4800 ROM ADDRESS 0 = 4f   6  3210
TMS4800 ROM ADDRESS 1 = 40   6      
TMS4800 ROM ADDRESS 1 = 40   6      
TMS4800 ROM ADDRESS 2 = 50   6 4    
TMS4800 ROM ADDRESS 2 = 50   6 4    
TMS4800 ROM ADDRESS 3 = 51   6 4   0
TMS4800 ROM ADDRESS 3 = 51   6 4   0
TMS4800 ROM ADDRESS 4 = 52   6 4  1 
TMS4800 ROM ADDRESS 4 = 52   6 4  1 
TMS4800 ROM ADDRESS 5 = 62   65   1 
TMS4800 ROM ADDRESS 5 = 62   65   1 
TMS4800 ROM ADDRESS 6 = 72   654  1 
TMS4800 ROM ADDRESS 6 = 72   654  1 
TMS4800 ROM ADDRESS 7 = 73   654  10
TMS4800 ROM ADDRESS 3 = 51   6 4   0
TMS4800 ROM ADDRESS b = a2  7 5   1 
TMS4800 ROM ADDRESS a = 92  7  4  1 
TMS4800 ROM ADDRESS 8 = 83  7     10
TMS4800 ROM ADDRESS 8 = 83  7     10
TMS4800 ROM ADDRESS 9 = 93  7  4  10
TMS4800 ROM ADDRESS 9 = 93  7  4  10
TMS4800 ROM ADDRESS a = 92  7  4  1 
TMS4800 ROM ADDRESS a = 92  7  4  1 
TMS4800 ROM ADDRESS b = a2  7 5   1 
TMS4800 ROM ADDRESS b = a2  7 5   1 
TMS4800 ROM ADDRESS c = b2  7 54  1 
TMS4800 ROM ADDRESS c = b2  7 54  1 
TMS4800 ROM ADDRESS d = b1  7 54   0
TMS4800 ROM ADDRESS d = b1  7 54   0
TMS4800 ROM ADDRESS e = b0  7 54    
TMS4800 ROM ADDRESS e = b0  7 54    
TMS4800 ROM ADDRESS f = c0  76      
TMS4800 ROM ADDRESS b = a2  7 5   1 
TMS4800 ROM ADDRESS 3 = 51   6 4   0
TMS4800 ROM ADDRESS 2 = 50   6 4    
TMS4800 ROM ADDRESS 0 = 4f   6  3210



If I look at the output from the 9316 at L2, it doesn't seem to obey strict ordering: however, the sequence is always the same:

If you skip spurious values you can see that it does count from 0 to F and back to 0 again.

It makes sense if you look at the output at a specific time, but I think that the TMS4800 will just look as soon as AR is active
with no delay.


Code

Adding some code to track the value of L2 (9316):

NETDEV_ANALOG_CALLBACK_MEMBER(update_id_1h) {  m_id_1h = (data > 2.5) ? 1 : 0; m_l29316_out = (m_id_8h << 3) | (m_id_4h << 2) | (m_id_2h<<1) | (m_id_1h); printf("UPDATE_id_1h TIME: %f  id_1h= %f  l29316_out=%x\n",time.as_double(),data,m_l29316_out); } 
NETDEV_ANALOG_CALLBACK_MEMBER(update_id_2h) {  m_id_2h = (data > 2.5) ? 1 : 0; m_l29316_out = (m_id_8h << 3) | (m_id_4h << 2) | (m_id_2h<<1) | (m_id_1h); printf("UPDATE_id_2h TIME: %f  id_2h= %f  l29316_out=%x\n",time.as_double(),data,m_l29316_out); } 
NETDEV_ANALOG_CALLBACK_MEMBER(update_id_4h) {  m_id_4h = (data > 2.5) ? 1 : 0; m_l29316_out = (m_id_8h << 3) | (m_id_4h << 2) | (m_id_2h<<1) | (m_id_1h); printf("UPDATE_id_4h TIME: %f  id_4h= %f  l29316_out=%x\n",time.as_double(),data,m_l29316_out); } 
NETDEV_ANALOG_CALLBACK_MEMBER(update_id_8h) {  m_id_8h = (data > 2.5) ? 1 : 0; m_l29316_out = (m_id_8h << 3) | (m_id_4h << 2) | (m_id_2h<<1) | (m_id_1h); printf("UPDATE_id_8h TIME: %f  id_8h= %f  l29316_out=%x\n",time.as_double(),data,m_l29316_out); } 



UPDATE_id_1h TIME: 0.000002  id_1h= 0.100000  l29316_out=0
UPDATE_id_1h TIME: 0.000002  id_1h= 3.999999  l29316_out=1
UPDATE_id_2h TIME: 0.000002  id_2h= 3.999999  l29316_out=3
UPDATE_id_1h TIME: 0.000002  id_1h= 0.100000  l29316_out=2
UPDATE_id_1h TIME: 0.000003  id_1h= 3.999999  l29316_out=3
UPDATE_id_4h TIME: 0.000003  id_4h= 3.999999  l29316_out=7
UPDATE_id_2h TIME: 0.000003  id_2h= 0.100000  l29316_out=5
UPDATE_id_1h TIME: 0.000003  id_1h= 0.100000  l29316_out=4
UPDATE_id_1h TIME: 0.000003  id_1h= 3.999999  l29316_out=5
UPDATE_id_2h TIME: 0.000003  id_2h= 3.999999  l29316_out=7
UPDATE_id_1h TIME: 0.000003  id_1h= 0.100000  l29316_out=6
UPDATE_id_1h TIME: 0.000003  id_1h= 3.999999  l29316_out=7
UPDATE_id_8h TIME: 0.000003  id_8h= 3.999999  l29316_out=f
UPDATE_id_4h TIME: 0.000003  id_4h= 0.100000  l29316_out=b
UPDATE_id_2h TIME: 0.000003  id_2h= 0.100000  l29316_out=9
UPDATE_id_1h TIME: 0.000003  id_1h= 0.100000  l29316_out=8
UPDATE_id_1h TIME: 0.000003  id_1h= 3.999999  l29316_out=9
UPDATE_id_2h TIME: 0.000003  id_2h= 3.999999  l29316_out=b
UPDATE_id_1h TIME: 0.000003  id_1h= 0.100000  l29316_out=a
UPDATE_id_1h TIME: 0.000003  id_1h= 3.999999  l29316_out=b
UPDATE_id_4h TIME: 0.000003  id_4h= 3.999999  l29316_out=f
UPDATE_id_2h TIME: 0.000003  id_2h= 0.100000  l29316_out=d
UPDATE_id_1h TIME: 0.000003  id_1h= 0.100000  l29316_out=c
UPDATE_id_1h TIME: 0.000003  id_1h= 3.999999  l29316_out=d
UPDATE_id_2h TIME: 0.000003  id_2h= 3.999999  l29316_out=f
UPDATE_id_1h TIME: 0.000003  id_1h= 0.100000  l29316_out=e
UPDATE_id_1h TIME: 0.000003  id_1h= 3.999999  l29316_out=f
UPDATE_id_8h TIME: 0.000003  id_8h= 0.100000  l29316_out=7
UPDATE_id_4h TIME: 0.000003  id_4h= 0.100000  l29316_out=3
UPDATE_id_2h TIME: 0.000003  id_2h= 0.100000  l29316_out=1
UPDATE_id_1h TIME: 0.000003  id_1h= 0.100000  l29316_out=0



Other weird things is that the 7493 at F2 seems to pick up spurious values, it should start at zero (which is does) but then immediately jumps to a value of 3?
It's supposed to be clocked by HBLANK, but that seems to fire very early when it should not.

Code
cnt = 0 time = 0.000000  time = 0.000000 data= 0.470887 
UPDATE_id_1v TIME: 0.000000  id_1v= 3.999999  f293_out=1
UPDATE_id_2v TIME: 0.000000  id_2v= 3.999999  f293_out=3   // why is this getting a value of 3?
UPDATE id_16v: 0.000000  id_16v= 3.999999  // the other 93 at H2 is doing the exact same thing 
UPDATE id_32v: 0.000000  id_32v= 3.999999  // the other 93 at H2 is doing the exact same thing getting a value of 3?
TMS4800 ROM ADDRESS 0 = 4f   6  3210
UPDATE abg: 0.000000  abg= 3.999999
UPDATE TEST2: 0.000000  data= 3.999999
UPDATE data7: 0.000000  data7= 3.999999
UPDATE data6: 0.000000  data6= 3.999999
UPDATE data5: 0.000000  data5= 3.999999
UPDATE data4: 0.000000  data4= 3.999999
UPDATE data3: 0.000000  data3= 3.999999
UPDATE data2: 0.000000  data2= 3.999999
UPDATE data1: 0.000000  data1= 3.999999
UPDATE data0: 0.000000  data0= 3.999999
UPDATE a4: 0.000000  a4= 3.999999
UPDATE a9: 0.000000  a9= 3.999999
UPDATE a10: 0.000000  a10= 3.999999
UPDATE abcd: 0.000000  abcd= 3.999999
UPDATE ld1b: 0.000000  ld1b= 3.999999
UPDATE vsync: 0.000000  vsync= 3.999999
UPDATE hblank: 0.000000  hblank= 3.999999   // hblank on?
TMS4800 ROM ADDRESS 400 = 0          
TMS4800 ROM ADDRESS 600 = 1         0
TMS4800 ROM ADDRESS 610 = 80  7       
UPDATE vld1: 0.000000  vld1= 3.999999
UPDATE hblank: 0.000000  hblank= 0.100000 // now hblank off?
UPDATE vsync: 0.000000  vsync= 0.100000
UPDATE a4: 0.000000  a4= 0.100000
TMS4800 ROM ADDRESS 600 = 1         0
UPDATE abg: 0.000000  abg= 0.100000
UPDATE_id_1v TIME: 0.000000  id_1v= 0.100000  f293_out=2
UPDATE TEST: 0.000000  data= 0.103274
cnt = 1 time = 0.000000  time = 0.000000 data= 1.183559 
UPDATE hblank: 0.000000  hblank= 3.999999  // now hblank on?
UPDATE a4: 0.000000  a4= 3.999999
UPDATE TEST: 0.000000  data= 3.435158

Looking at JD's Tank driver, it uses the PROM_MK28000 instead of the TMS4800. Trying that since it may have different timing and I get this:

[Linked Image from i.imgur.com]

Joined: May 2009
Posts: 2,048
Likes: 85
J
Very Senior Member
Offline
Very Senior Member
J
Joined: May 2009
Posts: 2,048
Likes: 85
As much as I'd love to, I can't really help you here, as it was long enough ago that I have no idea why what I implemented for Tank seems to work better.

Joined: Feb 2014
Posts: 852
Likes: 48
G
Senior Member
OP Online Content
Senior Member
G
Joined: Feb 2014
Posts: 852
Likes: 48
It's all good, JD. I'm just happy to have something that looks sane 8-)




I think I may have an answer for why the 7493 ends up with a value of 0x3, when it first updates A and B, the current code does an increment without even looking at the state of the clkA or clkB input, just increments both m_a and m_bcd "blindly".

Code
		NETLIB_HANDLERI(updA)
		{
			m_a ^= 1;
			m_QA.push(m_a, out_delay[0]);
		}

		NETLIB_HANDLERI(updB)
		{
			const auto cnt(++m_bcd &= 0x07);
			m_QBCD.push(cnt, out_delay);
		}

edit: Hmmm, changing this code made everything not work at all...

Joined: Feb 2014
Posts: 852
Likes: 48
G
Senior Member
OP Online Content
Senior Member
G
Joined: Feb 2014
Posts: 852
Likes: 48
After going back to the master version of fixfreq the screen seems to be syncing now.

The car is displaying but for some reason, it is jumping around horizontally and it seems to be skewed. However, it seems to remain on the same vertical position, which is good.


[Linked Image from i.imgur.com]

Joined: Feb 2014
Posts: 852
Likes: 48
G
Senior Member
OP Online Content
Senior Member
G
Joined: Feb 2014
Posts: 852
Likes: 48
I tried everything I could think of to make the horizontal counters work for the car display, and it finally occurred to me that for some reason the horizontal count is off by a couple of numbers.

So hard wiring the horizontal counter load to be a 6 instead of an 8 so that it will count two extra before hitting full, I can get the car to display in one place. The car doesn't move when the amount the counter has to count up matches the horizontal size of the screen.

However, it seems to display outside the area of the track. I stuck in a counter and hooked up the directions to the counter outputs to make it spin.

It runs pretty slow, but I'm generating tons of printfs.

edit: turned off all printfs and turned off the debugger and it runs pretty fast, though there's a lot of up and down screen movement.


Last edited by Golden Child; 06/28/22 08:21 PM.
Joined: Feb 2014
Posts: 852
Likes: 48
G
Senior Member
OP Online Content
Senior Member
G
Joined: Feb 2014
Posts: 852
Likes: 48
Ok, I'm able to move the car a little. I say a little because it's hard to move it since you're clocking a flip flop. It expects to get pulses. But it will move 8-)

Since the horizontal counter seemed to be two off, I changed the main horizontal counter to use the 1H instead of 2H when it computes the end of the line and it seems to work ok. (The first time I tried it it didn't work, then I remembered that I should change the horizontal counter load back to 8 instead of 6 to match).




I hacked a 74193 counter to drive the 1D1 .. 1D4 and 1R0..1R3 outputs and I can turn the car.

Code

	TTL_74193(TEST_ROT, P,  P, P,  P,      GROUND, P, P1_LEFT_RIGHT.2, P1_LEFT_LEFT.2)

	SWITCH(P1_LEFT_LEFT)
	SWITCH(P1_LEFT_RIGHT)

	NET_C(P1_LEFT_LEFT_GND.1, GND)
	NET_C(P1_LEFT_RIGHT_GND.1, GND)

	NET_C(P1_LEFT_LEFT.1, P1_LEFT_LEFT_GND.2)
	NET_C(P1_LEFT_RIGHT.1, P1_LEFT_RIGHT_GND.2)
	
	NET_C(P1_LEFT_LEFT.2, P1_LEFT_LEFT_PULLUP.2)
	NET_C(P1_LEFT_RIGHT.2, P1_LEFT_RIGHT_PULLUP.2)

	RES(P1_LEFT_LEFT_PULLUP, RES_R(1000))
	RES(P1_LEFT_RIGHT_PULLUP, RES_R(1000))

	RES(P1_LEFT_LEFT_GND, RES_R(100))
	RES(P1_LEFT_RIGHT_GND, RES_R(100))

	NET_C(P1_LEFT_LEFT_PULLUP.1, VCC)
	NET_C(P1_LEFT_RIGHT_PULLUP.1, VCC)

	ALIAS(1R0, TEST_ROT.QA)
	ALIAS(1R1, TEST_ROT.QB)
	ALIAS(1R2, TEST_ROT.QC)
	ALIAS(1R3, TEST_ROT.QD)


	ALIAS(1D1, TEST_ROT.QA)
	ALIAS(1D2, TEST_ROT.QB)
	ALIAS(1D3, TEST_ROT.QC)
	ALIAS(1D4, TEST_ROT.QD)

	ALIAS(SPEED_PULSE, P1_LEFT_UP.2)

	NET_C(P1_LEFT_UP.1, SWITCH_R.2)
	NET_C(SWITCH_R.1, VCC)
	
	RES(SWITCH_R, RES_R(100))
	SWITCH(P1_LEFT_UP)

	RES(SWITCH_R_GND, RES_R(1000))
	NET_C(SWITCH_R_GND.1, GND)
	NET_C(P1_LEFT_UP.2, SWITCH_R_GND.2)





Since it's so hard to keep pressing keys, I clocked it with 512V to create pulses

Code
	TTL_74193(TEST_ROT, P,  P, P,  P,      GROUND, P, RIGHT_PULSES.Q, LEFT_PULSES.Q)

	TTL_7400_NAND(LEFT_PULSES, P1_LEFT_LEFT_HIGH.Q, 512V)
	TTL_7400_NAND(RIGHT_PULSES, P1_LEFT_RIGHT_HIGH.Q, 512V)

	TTL_7404_INVERT(P1_LEFT_LEFT_HIGH, P1_LEFT_LEFT.2)
	TTL_7404_INVERT(P1_LEFT_RIGHT_HIGH, P1_LEFT_RIGHT.2)


	ALIAS(SPEED_PULSE, SPEED_PULSES.Q) 

	TTL_7408_AND(SPEED_PULSES, P1_LEFT_UP.2, 512V)


Last edited by Golden Child; 06/29/22 12:06 AM.
1 member likes this: robcfg
Joined: Feb 2014
Posts: 852
Likes: 48
G
Senior Member
OP Online Content
Senior Member
G
Joined: Feb 2014
Posts: 852
Likes: 48
There's some real strangeness with the timing and Netlist.

I thought I'd clean up my code and all of a sudden the horizontal counter wasn't working:


Why would swapping

Code
	TTL_7408_AND(HACK, 1H, P)  // see if changing it to 1H fixes the car
	TTL_7408_AND(E2_A, HACK.Q, 64H)  // see if changing it to 1H fixes the car
with
Code
	TTL_7408_AND(E2_A, 1H, 64H)

make it so the horizontal counter would have different behavior?



Code
#ifdef HORIZ_COUNTER_ADJ
#pragma message "USING 1H CLOCK " HORIZ_COUNTER_ADJ
//	TTL_7408_AND(E2_A, 1H, 64H)
	TTL_7408_AND(HACK, 1H, P)  // see if changing it to 1H fixes the car
	TTL_7408_AND(E2_A, HACK.Q, 64H)  // see if changing it to 1H fixes the car
#else
	TTL_7408_AND(E2_A, 2H, 64H)
#endif	
	ALIAS(2H_AND_64H, E2_A.Q)
	TTL_7410_NAND(J1_C, 2H_AND_64H, 128H, 256H) // 450th horizontal pixel (active low)
	// 256 + 128 = 384 + 64 = 448 + 2 = 450


edit: I tried such things as using a 4 input NAND and an 8 input NAND but neither 1H or 2H work properly. I must've found some combination of timing that works.

// TTL_7420_NAND(J1_C, 1H, 64H, 128H, 256H) // neither 1H or 2H work
// TTL_7430_NAND(J1_C, 1H, 64H, 128H, 256H, P, P, P, P) // neither 1H or 2H work


Guess I'm going to keep the ugliness if it works...

I managed to get the start button to work and it sets the counter to 78 but the score instantly jumps to 8 and the checkpoints aren't working yet, or the countdown.
(edit: looking at the nld_dm9314.cpp it seems that RS mode is not yet implemented for the 9314. That would keep the checkpoints from working 8-)


Another strange thing I'm noticing is that the UI doesn't seem to respond properly.

With a slow driver like netlist, you can bring up the UI menus, but then hitting Enter (to enter Input Settings for example) won't do anything and the UI kinda freezes to keyboard input, but the mouse pointer menu activity is still active.

It's kind of intermittent thing, sometimes it works other times it doesn't.

Joined: Feb 2014
Posts: 852
Likes: 48
G
Senior Member
OP Online Content
Senior Member
G
Joined: Feb 2014
Posts: 852
Likes: 48
Ok, modifying nld_dm9314.cpp to do some RS action:
Code
		NETLIB_HANDLERI(inputs)
		{
			netlist_time delay = NLTIME_FROM_NS(24); //FIXME!
			if (!m_MRQ())
			{
				/* Reset! */
				for (std::size_t i=0; i<4; i++)
					m_Q[i].push(0, delay);
			} else {
				for (std::size_t i=0; i<4; i++)
				{
					if (m_SQ[i]())
					{
						/* R-S Mode */
						// FIXME: R-S mode is not yet implemented!
						
						// RS mode is just an "extension of regular D mode"

						// way RS mode works is that D and S bar should be high (keeps old value)
						// S bar going low sets output high
						// Data going low and S bar high sets output low
						// S bar going low AND D going low sets output low (D takes precedence)

						if (!m_EQ())
						if (!m_D[i]())  // if D low and SQ high we clear the bit
						{
							m_last_Q &= ~(1 << i);
							m_Q[i].push((m_last_Q & (1<<i))>>i, delay);
						}
					}
					else  // SQ is Low
					{
						/* D Mode */
						if (!m_EQ())
						{
							m_Q[i].push(m_D[i](), delay);
							m_last_Q &= ~(1 << i);
							m_last_Q |= (m_D[i]() << i);
						}
					}
				}
			}
		}

And also realizing that I swapped the D and S parameters when I use the 9314, (really easy to do... 8-)

now I can do a full lap with the checkpoint scoring working!

Yes!


4 members like this: Stiletto, Just Desserts, robcfg, R. Belmont
Joined: Feb 2014
Posts: 852
Likes: 48
G
Senior Member
OP Online Content
Senior Member
G
Joined: Feb 2014
Posts: 852
Likes: 48
I made a PR for my gtrak10 stuff if you'd like to check it out.

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

Joined: May 2009
Posts: 2,048
Likes: 85
J
Very Senior Member
Offline
Very Senior Member
J
Joined: May 2009
Posts: 2,048
Likes: 85
Looks like you're pretty much YOLO-ing your way into a discrete driver. I like it. Bit tired to be doing any code review today, but if there's anything that Vas hasn't covered about 12-16 hours from now, I'll have a look.

Page 2 of 5 1 2 3 4 5

Link Copied to Clipboard
Who's Online Now
3 members (Duke, Darkstar, Richard Bannister), 22 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,100
Posts119,237
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