+Atari2600PAL Posted January 31 Author Share Posted January 31 Many thanks! Will play around with the EA5 version of the HSGPL software first Quote Link to comment Share on other sites More sharing options...
+Atari2600PAL Posted January 31 Author Share Posted January 31 9 hours ago, Lee Stewart said: This should work: VDPWA EQU >8C02 ;VDP Write Address *++ Writing registers in reverse order is TMS9918 safe. TEXT80 BYTE 0,>10,>4F,0,0,0,>88,>4F,1,6,1,>E8,3,>F0,4 ;registers VR14..VR00 *++ Change these ^^ ^^ for different FG/BG colors. *++ They should be the same values. The >4F is dark blue on white. The reverse *++ (white on dark blue) would be >F4 for each of those two registers. *++ Set up VDP registers VR00 to VR14 in reverse order... VRSET LI R0,TEXT80 ;load address register table for TEXT80 LI R1,VDPWA ;load VDP Write Address LI R2,>8E00 ;start at VR14..8 (MSb set) is register-write flag MOVB @TEXT80+13,@>83D4 ;VR01 value to scratchpad RAM screen timeout loc LIMI 0 ;don't need if interrupts already disabled VSET02 MOVB *R0+,*R1 ;copy next VDP register's value to VDP NOP ;delay..not sure we need it MOVB R2,*R1 ;write VR# and write-reg flag AI R2,>FF00 ;next register down JNO VSET02 ;write another register if not done ...lee Hi Lee, I've managed to assemble your code in EA and run it, many thanks When I run it the screen switches to 80 column mode which, as I'd expected, corrupts the EA screen, but that gets restored to normal if I press enter or something I'm currently reading the thread on assembly programming (and searching) for how to get the program to call/chain the HSGPL 80 column program (on the same disk) before it returns, but I don't know if this is even possible please? Many Thanks 1 Quote Link to comment Share on other sites More sharing options...
+Atari2600PAL Posted January 31 Author Share Posted January 31 Is EA3 some kind of pseudo program code? I opened my output file in a hex editor intending to copy the hex of the program (to then insert into a spare area of the HSGPL program) but instead of seeing, for example, a byte F4 (or 4F in your original) I see 2 bytes with the ascii codes for F4 😕 Many thanks Quote Link to comment Share on other sites More sharing options...
+mizapf Posted January 31 Share Posted January 31 EA3 is Option 3 of the Editor/Assembler cartridge (LOAD AND RUN). The actual file format is named "tagged object code" (which is loaded by option 3). There are two variants, a binary format that contains the real bytes (named "compressed", option "C" in the Assembler) and an ASCII representation that allows editing the object code in an editor. The tagged object code loaders of Editor/Assembler and of TI BASIC (with Editor/Assembler cartridge inserted) can load compressed code, while the TOC loader of Extended Basic cannot. 1 Quote Link to comment Share on other sites More sharing options...
+Atari2600PAL Posted January 31 Author Share Posted January 31 Thanks @mizapf Will re-assemble with option C then (I wondered what the manual meant by compressed format but it didn’t occur to me that’s what it meant!) Many thanks 1 Quote Link to comment Share on other sites More sharing options...
Asmusr Posted January 31 Share Posted January 31 6 hours ago, Atari2600PAL said: I'm currently reading the thread on assembly programming (and searching) for how to get the program to call/chain the HSGPL 80 column program (on the same disk) before it returns, but I don't know if this is even possible please? Most likely the HSGPL 80 column program is already setting up the VDP registers, so anything you do before loading it would be overwritten. The question is why the VDP setup isn't compatible with the F18A, and that would require either the source code or some difficult debugging to find out. Or perhaps Harald Glaap would know? Quote Link to comment Share on other sites More sharing options...
+Atari2600PAL Posted January 31 Author Share Posted January 31 3 minutes ago, Asmusr said: Most likely the HSGPL 80 column program is already setting up the VDP registers, so anything you do before loading it would be overwritten. The question is why the VDP setup isn't compatible with the F18A, and that would require either the source code or some difficult debugging to find out. Or perhaps Harald Glaap would know? I'm sure you are correct, but I thought it worth a go just to see what happens (am learning a lot) I've moved on to trying to edit the EA5 version now (I know it's not impossible since I know it did work) SNUG don't support the F18, I contacted them, but if someone knows them well enough to get the source code (or ask Harald to add support) we'd be sorted In the meantime I'm going to struggle on as I'm learning a lot about the workings of the 99 trying, even though I'll likely fail Thanks Quote Link to comment Share on other sites More sharing options...
Asmusr Posted January 31 Share Posted January 31 25 minutes ago, Atari2600PAL said: I'm sure you are correct, but I thought it worth a go just to see what happens (am learning a lot) I've moved on to trying to edit the EA5 version now (I know it's not impossible since I know it did work) SNUG don't support the F18, I contacted them, but if someone knows them well enough to get the source code (or ask Harald to add support) we'd be sorted In the meantime I'm going to struggle on as I'm learning a lot about the workings of the 99 trying, even though I'll likely fail Thanks Actually unlocking the F18A before running the software would be worth trying. Not because you can't place the F18A in 80 column mode before unlocking it, but because writing to higher registers than 7 without unlocking it will be masked to registers 0-7 and may corrupt the setup. To unlock the F18A just write >1c to register >39 twice. Quote Link to comment Share on other sites More sharing options...
+Atari2600PAL Posted January 31 Author Share Posted January 31 2 hours ago, Atari2600PAL said: Thanks @mizapf Will re-assemble with option C then (I wondered what the manual meant by compressed format but it didn’t occur to me that’s what it meant!) Many thanks Using option C is a great improvement But I don't get why every 2 bytes of Lee's TXT80 line is followed by >42 (>42 is also scattered around the code) Am sure there's an obvious reason for it, just not to me sadly Quote Link to comment Share on other sites More sharing options...
+Atari2600PAL Posted January 31 Author Share Posted January 31 28 minutes ago, Asmusr said: Actually unlocking the F18A before running the software would be worth trying. Not because you can't place the F18A in 80 column mode before unlocking it, but because writing to higher registers than 7 without unlocking it will be masked to registers 0-7 and may corrupt the setup. To unlock the F18A just write >1c to register >39 twice. Will have a look at that, thanks Setting 80 column text mode via EA then resets back to 40 column But I guess just unlocking the F18a might “stick” Many thanks Quote Link to comment Share on other sites More sharing options...
+Lee Stewart Posted January 31 Share Posted January 31 37 minutes ago, Asmusr said: Actually unlocking the F18A before running the software would be worth trying. Not because you can't place the F18A in 80 column mode before unlocking it, but because writing to higher registers than 7 without unlocking it will be masked to registers 0-7 and may corrupt the setup. To unlock the F18A just write >1c to register >39 twice. Pretty sure this is not the case. I write to registers 8..14 in fbForth to set up 80-column text with no problem. That mode persists until changed by my code. The only caveat is to never attempt 80-column text mode with the TMS9918 unless you write the registers in descending order because the TMS9918 definitely masks registers 0..7. ...lee Quote Link to comment Share on other sites More sharing options...
Asmusr Posted January 31 Share Posted January 31 (edited) 15 minutes ago, Lee Stewart said: Pretty sure this is not the case. I write to registers 8..14 in fbForth to set up 80-column text with no problem. That mode persists until changed by my code. The only caveat is to never attempt 80-column text mode with the TMS9918 unless you write the registers in descending order because the TMS9918 definitely masks registers 0..7. ...lee You're right, since F18A firmware 1.8, writes to registers > 7 are not masked if 80 columns mode is enabled. Edited January 31 by Asmusr Quote Link to comment Share on other sites More sharing options...
+mizapf Posted January 31 Share Posted January 31 1 hour ago, Atari2600PAL said: Using option C is a great improvement But I don't get why every 2 bytes of Lee's TXT80 line is followed by >42 (>42 is also scattered around the code) Well, that's the tag in Tagged Object Code. It indicates what the following two bytes mean: Binary data, absolute addresses, relocatable addresses, and more. See here: https://www.ninerpedia.org/wiki/Tagged_Object_Code Quote Link to comment Share on other sites More sharing options...
+Atari2600PAL Posted January 31 Author Share Posted January 31 2 minutes ago, mizapf said: Well, that's the tag in Tagged Object Code. It indicates what the following two bytes mean: Binary data, absolute addresses, relocatable addresses, and more. See here: https://www.ninerpedia.org/wiki/Tagged_Object_Code Ok, thanks. That makes sense, I had just assumed the C option saved just the pure code Quote Link to comment Share on other sites More sharing options...
+mizapf Posted January 31 Share Posted January 31 The tagged object code is a pretty intelligent save format; it allows for linking modules, relocation, segmentation, and more. However, since this requires some processing with each and every word, loading is quite slow. There is a tool (SAVE utility) which allows you to save a memory section to a file (as is), which can later be loaded by option 5 of Editor/Assembler. These program files are simple dumps of the memory area; you have to specify additional symbols (SFIRST, SLOAD, SLAST) which define the memory range to save. Compared to the PC world, the tagged object code is somewhat related to the EXE files (or ELF format in Linux), while the program files are more like the old COM files. 1 Quote Link to comment Share on other sites More sharing options...
+Atari2600PAL Posted January 31 Author Share Posted January 31 Well I wrote the code below, which I THINK should unlock the F18a, and then ran the HSGPL program but it still complains about the wrong VDP I think I'll look for a disassembler next Quote Link to comment Share on other sites More sharing options...
Tursi Posted January 31 Share Posted January 31 If it's complaining about "wrong VDP", then it's doing some form of 9938 detection which the F18A absolutely will not pass. You need to bypass the check and just let it go for it. 3 Quote Link to comment Share on other sites More sharing options...
Asmusr Posted January 31 Share Posted January 31 37 minutes ago, Atari2600PAL said: but it still complains about the wrong VDP Are you currently running the 80 column GROM 0 together with the 80 column DSR and the 80 column program? I mean, it's not just complaining that the components don't match? Quote Link to comment Share on other sites More sharing options...
+Atari2600PAL Posted January 31 Author Share Posted January 31 Just now, Asmusr said: Are you currently running the 80 column GROM 0 together with the 80 column DSR and the 80 column program? I mean, it's not just complaining that the components don't match? No. i don’t know if the grom0 actually has any mods for 80 column and the dsr shouldn’t come into it as the EA5 program is self contained (it seems happy to start even with no Hsgpl card) I’m actually just trying to run the EA5 in classic99 at the moment and, as far as I can see, that doesn’t allow the grom0 to be replaced (and mame doesn’t have any f18a support) Am going to try and learn how to use classic99 debugger and try to find where the vdp check is made Quote Link to comment Share on other sites More sharing options...
Tursi Posted January 31 Share Posted January 31 4 minutes ago, Atari2600PAL said: No. i don’t know if the grom0 actually has any mods for 80 column and the dsr shouldn’t come into it as the EA5 program is self contained (it seems happy to start even with no Hsgpl card) I’m actually just trying to run the EA5 in classic99 at the moment and, as far as I can see, that doesn’t allow the grom0 to be replaced (and mame doesn’t have any f18a support) Am going to try and learn how to use classic99 debugger and try to find where the vdp check is made Classic99 lets you replace any GROM by defining an entry in Classic99.ini that includes the replacement file. You'd want to have the GROM0 and any cartridge you need in the same cartridge entry, since they load together. But anything in the INI can overwrite the defaults. 1 1 Quote Link to comment Share on other sites More sharing options...
+Atari2600PAL Posted January 31 Author Share Posted January 31 Just now, Tursi said: Classic99 lets you replace any GROM by defining an entry in Classic99.ini that includes the replacement file. You'd want to have the GROM0 and any cartridge you need in the same cartridge entry, since they load together. But anything in the INI can overwrite the defaults. Ok, that’s great thanks Will give it a go tomorrow Quote Link to comment Share on other sites More sharing options...
Asmusr Posted January 31 Share Posted January 31 (edited) If you replace the instruction at >A2CE JNE >A2EA with JMP >A2EA it will bypass the VDP check. HSGPLE80 HSGPLE81 HSGPLE82 Edited January 31 by Asmusr 4 1 Quote Link to comment Share on other sites More sharing options...
RickyDean Posted January 31 Share Posted January 31 @Atari2600PAL, If this is a grom0 issue, I'd say that the HSGPL had a modified grom0 loaded into it like the Son of a Board from OPA, that was distributed with the TIM video upgrade. I have, in the past downloaded this grom0 upgrade with my GramKracker, and then pulled the SOB out and was able to use the SOB software in my GK. So you may have over wrote that grom 0 on your HSGPL? So if there are other grom0's with 80 capabilities built in, that might solve your problem. I don't know if you have PC99, which also sports a debugger I believe, but it has the SOB grom files included in the package. maybe this would help. But again, there are those here with a lot more experience on the matter. Quote Link to comment Share on other sites More sharing options...
atrax27407 Posted January 31 Share Posted January 31 There have been a couple of GROM0 files for the HSGPL that have been around for awhile. The Winfred Winkler GROM0 on the SNUG website and Tony Knerr's GROM0 both are "tried and true" for use with the HSGPL. As you said, the likely culprit is the HSGPL DSR which probably has F18A-incompatible code. Harald would be the one to ask about it. Quote Link to comment Share on other sites More sharing options...
+Atari2600PAL Posted February 1 Author Share Posted February 1 12 hours ago, Asmusr said: If you replace the instruction at >A2CE JNE >A2EA with JMP >A2EA it will bypass the VDP check. HSGPLE80 8.13 kB · 1 download HSGPLE81 8.13 kB · 1 download HSGPLE82 2.34 kB · 1 download @Asmusr Thank you, thank you, thank you That's worked brilliantly, many thanks! 2 Quote Link to comment Share on other sites More sharing options...
Like us on Facebook
Follow us on Twitter
AtariAge on Instagram
Watch us on YouTube
Chat on Discord
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.