7 replies to this topic

[gdement]

Has anyone built a78sign on linux? I've downloaded 2 different versions of the code, neither of them compile and I'm not certain which one is the correct version to use.

14298 Aug-15-2001
8503 Aug-10-2001

The conio.h version is bigger and (reportedly) 5 days newer, but since conio is a non-portable borland thing it seems like it would have been removed from a newer version, not added to it. Anyone know for sure which of these versions is the correct one?

There are various undefined functions, I could probably fix those as long as they're standard functions, but both versions need a file called nbtheory.h. I found one of these on google written by Wei Dai, but it doesn't seem to work at all and has lots of its own unsatisfied dependencies. I assume it isn't the file this program is supposed to be compiled with.

Have any of you linux people found a reasonable way to get a78sign working, or does it need to be partially rewritten? I can just run a78sign under windows, but I was hoping to develop under linux.
Thanks for any suggestions.

[Tom]

use bruce tomlin's new sign7800, which doesn't need any additional libraries and compiles just with a simple

gcc -o sign7800 sign7800.c

you can get it from this thread:
http://www.atariage....pic.php?t=52592

[gdement]

Thanks for the link. For some reason I missed that when I was searching the forums earlier. I tried it and like you said, it compiles easily. As it turns out, I've now discovered that the version of xmess I'm using apparently isn't running the BIOS code so I can actually test without the signature. Nevertheless, I now can generate them if needed. Thanks for your help.

And I should also thank Bruce Tomlin for writing it - your efforts are appreciated.

[Bruce Tomlin]

gdement said:

And I should also thank Bruce Tomlin for writing it - your efforts are appreciated.

It was something that I'd been wanting to do ever since I disassembled the encryption code in the 7800 ROM, and found that it did 960-bit math.

It's a good thing I downloaded the encryption program a few years ago, because all the Atari ST-based encryption programs have gone missing from the cgexpo site.

[gdement]

Correction - xmess is running the bootrom. I just didn't realize until now that I was running the PAL version, which of course doesn't check the sig and doesn't have a logo.

Having now run some code in NTSC, I've found that my display only works properly in PAL, which is kind of ironic since I'm in the US and never gave PAL any thought. Maybe my docs are written in British... Anyway, just wanted to correct that in case the "xmess not using the bios" comment sounded odd to anyone.

[Tom]

the most useful information about ntsc/pal frame timing i've found comes from some demo from eckhard stolberg (i think it's from the backdoor demo source)

; Differences between the NTSC and PAL 7800 consoles' output:
;     NTSC     PAL
;      15       15     automatic VBLANK lines
;      25       33     output lines, that can't be seen on many TVs
;     192      228     actual display lines
;      26       32     output lines, that can't be seen on many TVs
;       4        4     automatic VBLANK lines
;
;     262      312     total number of lines per frame
;     243      293     total number of DMA output lines per frame
;      60       50     frames per second
;
; So to make a NTSC game run properly on a PAL console, you can simply
; set up 25 extra blank lines before and after the normal NTSC display.
; Also you would have to adjust anything that is timed by counting the
; number of frames, since PAL consoles do less frames per second than
; NTSC consoles. The following routine detects if it is running on a
; NTSC or a PAL console by counting the number of scanlines per frame,
; so that you can make your game compatible with both TV standards.

maybe that helps you to find the error in your display stuff.

[Mitch]

Actually I think John Saeger wrote that demo but Eckhard probably had a hand in it as well.

Mitch

[gdement]

I found at least 1 bug and fixed it, but it didn't solve the display problem. I checked the number of lines in the DLL and it added up correctly, but I padded it anyway, which changed the screen corruption but didn't fix it. The code is just a simple thing I wrote to try and get something on the screen. It initially worked, but then scope creep took its toll.

The program allocates separate memory blocks for 2 display lists, 1 for each of 2 zones that get displayed. The 2nd zone is getting corrupted in ntsc mode somehow. I've tried lots of experiments but haven't figured it out. It really doesn't matter, because in a real project I would write a DL builder that packs all the display lists into a single 512 byte block of memory. This bug, whatever it is, results from a cheaply made "hello world" program that got out of hand. I doubt I'll ever bother fixing it.

Thanks for the PAL/NTSC reference - it is quite useful information even though it didn't lead to a solution in this case.