2600 in 2006

I'm just getting a black screen with jf.bin. Is there something I need to do to get a display?

Works for me (225 scanlines, though), and does look pretty neat. I haven't ever played Juno First; reminds me of Beamrider. (Didn't Manuel already say that?)

Works for me (225 scanlines, though), and does look pretty neat.  I haven't ever played Juno First; reminds me of Beamrider.  (Didn't Manuel already say that?)

Tried in z26 and it works. I still get a black screen in Stella 1.4.2 and 2.0. Someone should give it a go on real hardware.

I had a couple of kernels I wanted to test anyway, so I fired up the Kroko Cart. Juno First looks good on the TV (hacked to 262 lines). It's too bad the vertical movement is jumpy, but it's better than I could have done.

I had a couple of kernels I wanted to test anyway, so I fired up the Kroko Cart. Juno First looks good on the TV (hacked to 262 lines). It's too bad the vertical movement is jumpy, but it's better than I could have done.

 

Yeah, I messed up the scan line count. Sorry 'bout that.

Looks ! (I prefer the less jerky movement)

Hi John!

 

Pretty cool effect!

 

I'm not entirely sure what version you are refering to as jerky, I prefer the version the binary defaults to. (I think it's updated twice as often, with half the stepwidth or something like that?)

 

Any plans in continuing with this?

(It'd certainly help reducing my list of choices )

 

Greetings,

Manuel

Looks very good, although it doesn't work with Stella for me either. I actually hacked up a Juno kernel myself yesterday using a beamrider/solaris style display, and the result is posted in my blog. However, your version looks better as it is more faithful to the original.

 

Chris

Any plans in continuing with this?

(It'd certainly help reducing my list of choices )

 

Not really, actually. When I read about your thinking about JF, I figured that any good JF game ought to have the scrolling dot thingies since--regardless of whether they really affect gameplay--they are a defining aspect of the game's visuals.

 

I'm not really interested in writing the game myself, but wanted to if possible prevent the 'crime' of someone releasing a JF game without the dotty background.

 

So I'll offer you my full source code for the demo, including the code generator, gratis to anyone who wants it. I'll even do a bit of a write-up for it and offer any help you may need.

 

Some preliminary points:

 

-1- The code generator is written in QBASIC. I think QBASIC is available free on Microsoft's web site someplace; it's certainly not hard to find.

 

-2- Each row of dots is stored as a starting position and a string of digits; each digit is the number of cycles to the next dot, minus six. So if there should be six dots, starting at position 10, and there should be seven cycles between them except between the third and fourth where there are eight, that row would be generated as a 10 in the start array and a "11211". Note that the string is five characters because six dots will have five "gaps".

 

-3- Seven cycles was chosen as the minimum dot spacing because that's the time for "STA RESBL / DEY / BEQ exit". Larger spacings use STA.W or add NOPs. I use overlapping code for different dot spacings and using the above means the code generator can be pretty simple. I could have accommodated closer dots and still gotten some code overlap if I'd generated "STA RESBL / DEY / STA RESBL / BEQ exit" but since such code sequences could only exit at the BEQ the code generator would have to be more complicated.

 

-4- The code generator right now works by generating the strings top to bottom. When generating each string, it checks to see if the master template string W$ already contains it. If not, it appends to W$, borrowing from the end of W$ if possible (e.g. if W$ ends with "112112" and I want to add "11212", I would just add the "12" to W$ so it would end with "11211212". A better packing algorithm could probably avoid some redundancy here.

 

-5- Because of branching restrictions, the generated code has to be split into pages. The existing algorithm is very crude and makes no effort to find the best arrangement of code into pages.

 

-6- To make things quick-and-easy, I used four-byte entries for each row in the master table. This is rather expensive. If the screen is 32 dots tall (as at present), each horizontal scroll position will take up 128 bytes. Since I would expect there to be less than 256 entry points into the dot-drawing code, and since both the starting delay and number of dots are always less than 15, it should be possible to compress this into two bytes/row.

 

-7- At present, the generated code for each line starts with "STA WSYNC/LDY #2/STY ENABL". It may be more useful to do something like "LDA #2/STA RESBL/STA ENABL" sometime in the line before the dot line, and then starting the dot line with "STA WSYNC/STA GP0". If VDELP1 is set, this would allow for clean sprite shape updates.

 

-8- Because there are no delay registers for missile enables, it may be difficult to get those done without 'tearing' in the line following a dot line. I would suggest that it may be useful to compute two double-lines worth of missle data earlier in the kernel, so that immediately following a dot line the kernel can simply "LDA missiles / STA ENAM0 / ASL / STA ENAM1". If missiles are only one double-scan-line high, that might not be necessary: set up SP before invoking the dot line, then after the dot line do "cpx missiley1 / php / cpx missiley2 / php".

 

Let me know if you need any other assistance.

I'm getting a black screen in Stella, too. I did check out Chris' demo, and that looked pretty good already.

 

I played Juno First quite a bit, and I don't think the horizontal movement is very important, since you really don't move left or right very far before the grid reaches its "edge". But the vertical speed/direction of your ship is critical. (Just my 2¢.)

Hi there!

 

Any plans in continuing with this? (It'd certainly help reducing my list of choices )

Not really, actually.

 

Hm... hehe, let's see next if Chris will continue with it then

 

I'm not really interested in writing the game myself, but wanted to if possible prevent the 'crime' of someone releasing a JF game without the dotty background.

 

I think it'd depend on the price you have to pay for the dots. If they get so "expensive" that other, more important things of the gameplay will suffer, I'd rather choose another comprise.

 

So I'll offer you my full source code for the demo, including the code generator, gratis to anyone who wants it.  I'll even do a bit of a write-up for it and offer any help you may need.

 

Again, thanks a lot for this offer!

 

-1- The code generator is written in QBASIC.  I think QBASIC is available free on Microsoft's web site someplace; it's certainly not hard to find.

 

Wow, it's been a while since I last saw that. Back in school everyone was hacking Nibbles

 

Let me know if you need any other assistance.

 

Ok, cool. Thanks again!

 

Greetings,

Manuel