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:
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.
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".
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.
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.
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.
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.
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!
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.
![[Linked Image from i.imgur.com]](https://i.imgur.com/vxZ4KnB.png)
![[Linked Image from i.imgur.com]](https://i.imgur.com/vaD0F59.png)
