Page 3 of 7

Re: Atari EPG jr reverse engineer

Posted: Sat May 15, 2010 6:24 pm
by AriX
Here it is: http://prevueguide.com/uvsgenerator.php
I took out emumode support since it wasn't working... Barely a difference anyway, just command size and "e" instead of "c" to edit :p
I also changed some things and added support for defining a custom time and date.

Re: Atari EPG jr reverse engineer

Posted: Sat May 15, 2010 7:15 pm
by Bolt96
Okay now I have a better understanding of how the codes are inserted via PLus monitor, but how would you insert the codes using the cgi scripts? I've downloaded Apache 2.2 and extracted the files in the zip to "C:/program files/apache software foundation/apache2.2/cgi-bin" but I'm unsure as how to activate them. And also how to access the site you posted..

Re: Atari EPG jr reverse engineer

Posted: Sat May 15, 2010 7:36 pm
by AriX
Bolt96 wrote:Okay now I have a better understanding of how the codes are inserted via PLus monitor, but how would you insert the codes using the cgi scripts? I've downloaded Apache 2.2 and extracted the files in the zip to "C:/program files/apache software foundation/apache2.2/cgi-bin" but I'm unsure as how to activate them. And also how to access the site you posted..
Sorry, made a mistake in my post. Link updated. You don't need the cgi-bin thing if you just use the link I posted on my site :)

Re: Atari EPG jr reverse engineer

Posted: Sat May 15, 2010 8:05 pm
by Bolt96
Oh thank you! :)

Re: Atari EPG jr reverse engineer

Posted: Sat May 15, 2010 10:48 pm
by swest77
but altirra has a problem in that it doesn't recognise the escape key
Possibly a stupid thought, but have you tried the Ctrl-[ key sequence? That's the official escape CTRL code from the teletype terminal days, and because many desktop computer platforms which came along afterwards (IBM, Apple, Commodore, etc.) emulated support for those codes, Ctrl-[ will often be seen by old programs as the ESC keyboard key itself.

More specific explanation: ascii character 27 (1Bh) was the escape character in the teletype days. Just as pressing the space bar generated ASCII 32, pressing ESC generated ASCII 27. And for keyboards without escape keys, "they" chose Ctrl-[ as another way of sending ASCII 27. Anyway, then along come home desktop computer platforms, and their makers not wanting to upset old habits, many coded their BIOSes to put ASCII 27 in the keyboard read interrupt when either the ESC key, or Ctrl-[, was pressed. Thus if software was written to do 8-bit reads from the keyboard read interrupt, they would look for 27 to know when ESC had been pressed -- yet wouldn't know if the real ESC key was pressed or if Ctrl-[ was pressed, causing either one to work equally well in the end.

Not sure about the Atari platform, but as an aside, in the IBM world, 16-bit keyboard read interrupts also exist in addition to older style 8-bit keyboard read interrupts. When a key is pressed, these 16-bit interrupts return two (instead of one) bytes (i.e. a 16-bit word), where the low 8 bits contain the traditional ASCII value for the key that was pressed (e.g. 27 for escape), but where the high 8 bits contain what is called a "scan code". Scan codes were essentially created because by the time of the IBM PC's invention, keyboards were having more and more keys, especially ones for which no traditional teletype-era ASCII values existed. E.g., the F1, F2, and F3 keys on IBM compatible PCs (and thus on today's Windoze PCs) return 3B00, 3C00, and 3D00 (scan codes 3B, 3C, and 3D, but traditional ASCII codes all 0). Scan codes were also used to distinguish between keys that were duplicated on keyboards. E.g., numeric pad up_arrow = 4800, and numeric pad PgUp = 4900 ... but regular up_arrow = 48E0, and regular PgUp = 49E0. Point of all this is: when reading the keyboard via a 16-bit interrupt, real ESC = 1A1Bh, but Ctrl-[ = 011Bh.

So assuming the Atari platform used 27 (1Bh) for ESC and also made Ctrl-[ deliver 27, then it's possible that if the emulator doesn't support the ESC key at the hardware level, Ctrl-[ will still generate 27. If that's true, then if the EPG software only pays attention to the low 8 bits, Ctrl-[ might just bring up its menu. :)

I just know that Windows itself reads 16-bit all the time, so Ctrl-[ never fools Windows programs into thinking ESC has been pressed. But when I run my old DOS programs, Ctrl-[ fools most of them into thinking ESC was pressed, because they're only checking the keyboard 8-bit style.

Re: Atari EPG jr reverse engineer

Posted: Sun May 16, 2010 6:58 am
by tin
AriX wrote:Here it is: http://prevueguide.com/uvsgenerator.php
I took out emumode support since it wasn't working... Barely a difference anyway, just command size and "e" instead of "c" to edit :p
I also changed some things and added support for defining a custom time and date.
Gutted! what didn't work about the multi emulator support? did work fine here. It also changed the max length of a hex string it produced, as Atari800win doesn't seem to like anything longer than ~32 bytes, but altirra was OK with it. The changes were only to make it simpler to cut-n-paste long things, which I guess we'll be having soon when more modes are discovered :)

Re: Atari EPG jr reverse engineer

Posted: Sun May 16, 2010 7:36 am
by tin
swest77 wrote:
but altirra has a problem in that it doesn't recognise the escape key
Possibly a stupid thought, but have you tried the Ctrl-[ key sequence?
unfortunately no dice with Ctrl-[ :(

wow, intimite knowledge of keyboards!!! ;) In atari land, it seems (this is all new to me) that the raw keyboard code is 1C, this is translated to ASCII as 1B, no matter what modifier is pressed (and no other keyboard combination returns 1B at this stage) then our code has some funky translation thing that changes it to 5B. The code then looks for an incoming Keypress of 5B to do the escape routines.

Re: Atari EPG jr reverse engineer

Posted: Sun May 16, 2010 10:03 am
by AriX
tin wrote:
AriX wrote:Here it is: http://prevueguide.com/uvsgenerator.php
I took out emumode support since it wasn't working... Barely a difference anyway, just command size and "e" instead of "c" to edit :p
I also changed some things and added support for defining a custom time and date.
Gutted! what didn't work about the multi emulator support? did work fine here. It also changed the max length of a hex string it produced, as Atari800win doesn't seem to like anything longer than ~32 bytes, but altirra was OK with it. The changes were only to make it simpler to cut-n-paste long things, which I guess we'll be having soon when more modes are discovered :)
It got stuck in Altirra mode and wouldn't change even when I changed the $_GET parameter in the URL, and since the feature is useless for me (Atari800MacX has copy/paste support), I just took it out. I'd be happy to put it back in if you'd like.

UPDATE: Put it back in, works fine now. I don't know why it was broken before, sorry about that.

Re: Atari EPG jr reverse engineer

Posted: Sun May 16, 2010 10:34 am
by Metalguy66
I can test this on real hardware..

When I send serial data from tm PC through an SIO2PC interface into my 130xe's SIO port, with the Prevue cart running, you can see the little DATA cursor flash.. And.. I have my 130xe hooked up to a video capture card on my PC..

So I can send strings of data into the thing, and then capture it's output as Mpeg or AVI.. and send it to you guys..

Re: Atari EPG jr reverse engineer

Posted: Sun May 16, 2010 10:47 am
by AriX
Metalguy66 wrote:I can test this on real hardware..

When I send serial data from tm PC through an SIO2PC interface into my 130xe's SIO port, with the Prevue cart running, you can see the little DATA cursor flash.. And.. I have my 130xe hooked up to a video capture card on my PC..

So I can send strings of data into the thing, and then capture it's output as Mpeg or AVI.. and send it to you guys..
Cool! :D