Sixteen digit kernel demo (no flicker, no blinds)

[supercat]

Here's a little demo that shows 16 digits per line, without venetian blinds, flicker, or 'zig'. The temp RAM requirement is significant but not unreasonable (slightly under 32 bytes) and the code/tables are large but not huge (the demo is under 2K). The time to set up to display each line is significant but not outrageous (the demo shows eight lines of sixteen digits each); using another K or so worth of tables would cut setup time in half.

 

To use this demo, move the cursor with the joystick and press fire to change a digit. All 128 digits may be set independently.

 

So who can figure out how it works?

score16.bin

[djmips]

Very cool. 2

 

However, it doesn't work on my Atari Jr. (made in Taiwan in August 1989 so it's an infamous late model.)

 

I'll dig out a 4 switcher...

Edited November 23, 2005 by djmips

[supercat]

However, it doesn't work on my Chinese Atari Jr. 

970628[/snapback]

 

What does it do?

[djmips]

Here's a link to some info posted with regard to some HMOVE differences..

 

HMove problems on Hunchy with late model JR

 

It looks like this (very approximate). Ignore the missing digit in column 16 (was flashing)

 

[+batari]

Here's a link to some info posted with regard to some HMOVE differences..

\

HMove problems on Hunchy with late model JR

970631[/snapback]

According to a z26 trace log, you have cycle 73 HMOVEs. What I want to know is if cycle 74 HMOVEs will work the same on a Jr? I hope so...

[Cybergoth]

Hi there!

 

So who can figure out how it works?

 

Phew, beats me... from the positioning irregularities I'd assume it requires mid-scanline RESP trickery?

 

Greetings,

Manuel

[Thomas Jentzsch]

So who can figure out how it works?

You display lots of 8s and hide the superfluous parts with the playfield.

 

Very clever. Perfect for emulating 7 segment displays. Unfortunately some letters/digits aren't possible with those displays (e.q. Q, W,) or indistinguishable.

 

Still, a very cool demo!

[Cybergoth]

Hi there!

 

You display lots of 8s and hide the superfluous parts with the playfield.

 

Oh... I got the first part, but I thought the hiding was more complicated. Silly me... at first I was even suspecting it was hiding stuff under the playfield like Robert did in his demos, but with the space in the middle of the digit being only 3 pixels I dropped this theory too soon

 

Greetings,

Manuel

[Zach]

Very clever, John. [applause]

Edited November 23, 2005 by Zach

[+Andrew Davie]

Very clever, John. [applause]

970691[/snapback]

 

Nah, he stole this idea after I mentioned a technique developed back in the 1600s, called DigiView. He sneakily changed the name and appropriated the technique as his own. I'm not impressed at all. Fortunately there are people like me sitting here on my butt and otherwise doing fuck-all, able to point out these sort of things.

 

[Thomas Jentzsch]

Fortunately there are people like me sitting here on my butt and otherwise doing fuck-all, able to point out these sort of things.

Thank you! Thank you! Thank YOU! How would the world survive without those modern heroes?!

 

Terribly Remarkable Omniscient Level-headed Look-out Saints they are :!:

 

[supercat]

Try this version

score16.bin

[+batari]

The first thing that popped in my head when I saw this demo was this:

[djmips]

And I was thinking Sudoku.

 

 

[supercat]

The first thing that popped in my head when I saw this demo was this:

(Minesweeper)

971010[/snapback]

 

Minesweeper would be easy if one accepts the limitations of the display kernel (e.g. constructing seven-segment shapes for everything). What I was thinking would be a more interesting challenge, though, would be to construct a minesweper game using flicker or blinds with a grid of more than 200 cells. The Atari's got plenty of memory to hold the necessary raw information (just need 50 bytes for that), but dealing with the information real-time would be an interesting challenge.

 

I would think it might be doable, if one uses the middle six bits of each byte to hold the 'bomb' status of six squares, and has the outer two bits 'borrow' the status from the neighboring byte. The challenge thus becomes turning twenty-four bits into six counts. Time for some impressive lookup tables.

 

Obviously doing everything with one lookup would be out of the question--24 bits would represent a 16MB table. No problem for a Pentium, but a bit much for the poor 6507 to handle.

 

There are ways of reducing the table size to something reasonable, though.

 lda above,x
 eor therow,x
 eor below,x
 sta bit0
 lda above,x
 ora therow,x
 ora below,x
 sta bit1
 lda above,x
 and therow,x
 and below,x
 eor bit1
 sta bit1
; Number of bombs in a column and bit1:bit0
; 0=00 1=11 2=10 3=01

Now I've reduced the number of bits to be dealt with from 24 to 16. Almost reasonable. Now let's split the problem in thirds and that will get the size to 8.

 ldy bit1
 lda bit0
 and #$0F
 eor shiftleft4,y
 tay
 lda lookup1,y
; Do something with BCD (or whatever) readout for right two cells
 ldy bit0
 lda bit1
 and #$3C
 eor shiftout2,y; Left 2 bits left 2 and right 2 bits right 2
 tay
 lda lookup2,y
; Do something with BCD (or whatever) readout for middle two cells
 ldy bit0
 lda bit1
 and #$0F
 eor shiftleft4,y
 tay
 lda lookup1,y
; Do something with BCD (or whatever) readout for left two cells

 

Note that there are 45 different pairs of digits that may appear in a Minesweeper game, so the value read out could be used directly as a character code in a "font" consisting of digit pairs.

[Zach]

And I was thinking Sudoku. 

 

 

971022[/snapback]

 

You're not alone. Given a starting position, you could basically play Sudoku on this demo as-is. The trouble though is how to draw a grid. As great as Supercat's demo is, I think Robert M.'s 13 character display is better suited for Sudoku.

[Thomas Jentzsch]

The trouble though is how to draw a grid.

We could use the missiles for (thin) vertical lines and the playfield for horizontal lines.

[Zach]

The trouble though is how to draw a grid.

We could use the missiles for (thin) vertical lines and the playfield for horizontal lines.

971308[/snapback]

I had considered that, but wouldn't the PF that covers part of the 8's also cover missiles?

[djmips]

Try this version

970740[/snapback]

 

That version fared no better on my Cuttle Cart and '89 Jr.

[Thomas Jentzsch]

I had considered that, but wouldn't the PF that covers part of the 8's also cover missiles?

Sure, but since we only use 9 (out of 16) columns, there is plenty of space between. There we don't need PF masking and can display the missiles.

[Zach]

Sure, but since we only use 9 (out of 16) columns, there is plenty of space between. There we don't need PF masking and can display the missiles.

971656[/snapback]

Of course. So every fourth position would be a missile instead of an 8. I guess you'd have to use the multi-sprite trick on the missiles too to get the correct spacing. It's nice that whoever decides to program Sudoku has options.

[+batari]

Try this version

970740[/snapback]

 

That version fared no better on my Cuttle Cart and '89 Jr.

971636[/snapback]

This version has HMOVEs during HBLANK, as it should (STA HMOVE is at cycle 2 instead of 0, but I think this should still work even on a Jr.) This could mean that the problem is not with HMOVE at all, but with RESPx.

 

I think that this still leaves the cycle 74 HMOVE question unanswered. Please try this binary and tell us what happens:

 

http://www.atariage.com/forums/index.php?a...e=post&id=44182

[djmips]

I think that this still leaves the cycle 74 HMOVE question unanswered.  Please try this binary and tell us what happens:

http://www.atariage.com/forums/index.php?a...e=post&id=44182

971831[/snapback]

 

works.