Jump to content
IGNORED

Pageable ROM?


First Spear

Recommended Posts

Listening to an Intellivisonaries segment in the 2014 Christmas Special Edition episode. Keith Robinson, a little after the 2-hour mark, discussed "Pageable ROM". I am not sure if he is saying that it would only be useful for multi-carts (like Go for the Gold), or if it would be a way to also be used for new games.

 

I am getting my metaphors mixed up between paging ROM and paging RAM and swapping GRAM with RAM.

 

Can someone straighten me out on the definitions?

 

 

Thanks.

Link to comment
Share on other sites

I'm pretty sure Keith was referring to the scheme Mattel had adopted for switching 4K chunks of ROM in and out. The ECS, World Series Major League Baseball, Go For The Gold, and a few in-development titles made use of it. Mattel used it for both. (Go For The Gold is an "album" title—aka. "multii-cart"—while WSMLB is not.)

 

The Mattel scheme allows stacking up to 16 4K-word ROM pages in a single 4K-word region of the memory map. In theory, that would allow for up to 64K-words x 16 = 1M-words of game ROM if you could apply it to the entire memory map. You can't, however, because of various fixed things such as the STIC, GRAM, GROM, System RAM, PSG, EXEC, etc.

 

In the Mattel scheme, the address space is divided into 16 4K-word segments. For ease of typing, I'll just refer to those as $0xxx, $1xxx, $2xxx, ... $Fxxx, to refer to the 4K word ranges $0000-$0FFF, $1000-$1FFF, $2000-$2FFF, etc.

 

Each 4K-word segment is either page-flipped (pageable) or fixed.* A fixed segment's contents doesn't change. For example, $1xxx is fixed and will always contain the EXEC. $3xxx is fixed and will always contain GROM/GRAM.

 

A page-flipped segment can select among 16 different ROM segments (or, RAM even) in that segment. Programs write a special value to memory to flip among the 16 possible pages. If the program asks for a page that isn't present in the system, then that segment reads back as $FFFF. The association of pages to segments is fixed in the ROM, and each page-flipped segment can have up to 16 pages of its own. I could go into further details, but I've actually described the scheme multiple times here in the forum. :-)

 

Anyway, there's nothing in this scheme that limits it to simply "album cartridges" / "multi-carts." WSMLB uses two pages ($F000 PAGE 0, $F000 PAGE 1) for speech data. My port of Colossal Cave uses this scheme to map the colossal game database into memory. (128K bytes.) (And no, it's not available yet.)

 

 

This use of the term "paging" is slightly different than the concept employed in virtual memory operating systems. Here, flipping a ROM page is a deliberate act made by the game program. It says (in code): "Show me something different now at $Fxxx!". Paging in the modern OS context is usually something handled behind the scenes. The OS page fault handler says (again in code): "Oh crap, the program asked for a byte at location X, but that's on disk. Let's go find it and patch things up so it doesn't notice."

 

 

 

------------------------------------------------------------------------------------------------------------------------------

* WSMLB is hybrid. It maps a fixed page at $Exxx which overlaps the page-flipped page in the ECS. WSMLB immediately switches out the ECS page so there's no conflict, and then treats it as a fixed page from there on out.

  • Like 2
Link to comment
Share on other sites

Yeah. Paging is one of those terms that has multiple uses, which all really refer to the same thing - but the modern use has become extremely specific.

 

"Paging" in a general sense just refers to memory allocation in fixed lengths, or "pages" - as opposed to any length allocations. Virtual memory implementations tend to work on this, which is why it's become synonymous with it. However there are still architectures out there that are heavily page-based, so you still do see the terms "paging" and "page-level operation" from time to time, that have nothing to do with virtual memory. IBM (being very oldschool) uses the term heavily to describe nearly everything even today.

 

So whether you're moving data between ROM and RAM, or just within RAM, it's still paging at least in the old school sense. Although the Intellivision doesn't have a fixed-length page concept that I'm aware of (intvnut will correct me if I'm wrong here), there's always some minimum data size that you can move. A lot of old school guys often used "paging" to refer to ANY large chunk of memory allocation, even if variable length. Confusing, yes. Moving data between ROM/RAM and GRAM could be called "paging" by some.

 

Incidentally, "swapping" has also become nearly synonymous with "paging", making things even more clear as mud.

 

ROM paging on the INTV, today, is pretty much unnecessary unless you're coding a HUGE game.

  • Like 1
Link to comment
Share on other sites

ROM paging on the INTV, today, is pretty much unnecessary unless you're coding a HUGE game.

 

FWIW, Kroz actually uses some paging. It may not have been strictly necessary, but it certainly afforded us a favorable development time vs. size tradeoff. I added it fairly late in the dev cycle so we could focus on finishing the game, vs. optimizing for size (and potentially breaking things as we did so). In this case, the size vs. speed tradeoff was in terms of size vs. development speed. ;-)

 

 

Although the Intellivision doesn't have a fixed-length page concept that I'm aware of (intvnut will correct me if I'm wrong here), there's always some minimum data size that you can move.

 

Well in the Mattel paged ROM scheme, pages are always 4K words on a 4K word address boundary. And, you're not really moving anything. You're just selecting one of 16 pages of data to be visible at that particular address window for a game with paged ROMs.

 

Here are some visualizations (which may only make sense to me) of how Go For The Gold, WSMLB and the ECS are structured. Each of these has some paged ROM, and for Gold and WSMLB, some fixed ROM (which I've represented as occupying all pages). Boxes with a dash indicate pages that are empty and read as $FFFF. There's no ROM or RAM mapped there.

 

Go For The Gold:

 

post-14113-0-71693500-1420100398_thumb.png

WSMLB:

 

post-14113-0-35499500-1420100408_thumb.png

 

The ECS EXEC ROM:

 

post-14113-0-63401000-1420100416_thumb.png

 

 

  • Like 1
Link to comment
Share on other sites

Was there an actual reason GFTG was paged? Given that the address space is large enough, couldn't they just have the entire game visible and have the game point to whatever was necessary? Was it due to the size of ROM chips back in the day?

 

Do you actually mean GFTG or WSMLB? The Go For The Gold is a "multi-cart" of multiple existing games, so it was indeed easier to just put them all in the same memory space and use "paging" to make the selected game visible. That way, they all could execute as originally designed, as if they were the only program.

Edited by DZ-Jay
Link to comment
Share on other sites

 

Do you actually mean GFTG or WSMLB? The Go For The Gold is a "multi-cart" of multiple existing games, so it was indeed easier to just put them all in the same memory space and use "paging" to make the selected game visible. That way, they all could execute as originally designed, as if they were the only program.

 

GFTG.

 

I guess I'm spoiled with IntyBASIC. To me, taking 4 4k games and bundling them together along with a menu would take all of 5 minutes. Unless these games did some real unusual tricks with memory addressing or something...

Link to comment
Share on other sites

 

GFTG.

 

I guess I'm spoiled with IntyBASIC. To me, taking 4 4k games and bundling them together along with a menu would take all of 5 minutes. Unless these games did some real unusual tricks with memory addressing or something...

 

That's fine in IntyBASIC, where the location of code is transparent to the programmer. In Assembly, they probably had hard-coded memory locations, branches, dispatch tables, or anything driven by pointer arithmetic. Remember, in order to fit games into 4K, they usually had to apply some clever tricks at times.

 

Besides, as any QA technician will tell you, anything that allows you to not change the original code is always preferable to the alternative. :)

 

-dZ.

  • Like 1
Link to comment
Share on other sites

Was there an actual reason GFTG was paged? Given that the address space is large enough, couldn't they just have the entire game visible and have the game point to whatever was necessary? Was it due to the size of ROM chips back in the day?

 

I think they were dropping in the original ROMs as-is without reassembling them. And, you don't have to worry about symbol clashes either, if you were to try to integrate them in One Big Game. That way, all they needed to do is write the title screen / music / etc. and they're ready to go. (Interestingly, they took the opposite approach with Triple Challenge.)

 

In fact, you can build a working Go For The Gold launcher from the pieces they give you on Intellivision Lives! This working GFTG will play in jzIntv at least (and on real hardware with a JLP board or LTO Flash!). Here's how I did it:

 

  • Concatenate gold.bin, skiing.bin, hockey.bin, boxing.bin and bsktball.bin into one big .bin file. (Concatenate in that order.)
  • Use the config file below with it.

.

[mapping]
$0000 - $0FFF = $5000 PAGE 0
$1000 - $1FFF = $6000
$2000 - $2FFF = $5000 PAGE 6  ; Skiing
$3000 - $3FFF = $5000 PAGE 5  ; Hockey
$4000 - $4FFF = $5000 PAGE D  ; Boxing
$5000 - $5FFF = $5000 PAGE 8  ; Basketball

.

In Windows you can do the first step with a command like this (assuming all files are in the current directory:

.

copy gold.bin/b + skiing.bin/b + hockey.bin/b + boxing.bin/b + bsktball.bin/b gold2.bin

.

In Linux / Mac OS X, the command is similar and slightly simpler:

.

cat gold.bin skiing.bin hockey.bin boxing.bin bsktball.bin > gold2.bin

.

And then just name the config above "gold2.cfg", et voila! You should now have a working Go For The Gold launcher that launches the four games. IIRC, Skiing has a slight race condition issue where occasionally the color stack gets corrupted when you try to launch it. Otherwise, it works pretty well.

  • Like 5
  • Thanks 1
Link to comment
Share on other sites

  • 1 month later...

 

I think they were dropping in the original ROMs as-is without reassembling them. And, you don't have to worry about symbol clashes either, if you were to try to integrate them in One Big Game. That way, all they needed to do is write the title screen / music / etc. and they're ready to go. (Interestingly, they took the opposite approach with Triple Challenge.)

 

In fact, you can build a working Go For The Gold launcher from the pieces they give you on Intellivision Lives! This working GFTG will play in jzIntv at least (and on real hardware with a JLP board or LTO Flash!). Here's how I did it:

 

  • Concatenate gold.bin, skiing.bin, hockey.bin, boxing.bin and bsktball.bin into one big .bin file. (Concatenate in that order.)
  • Use the config file below with it.
.
[mapping]
$0000 - $0FFF = $5000 PAGE 0
$1000 - $1FFF = $6000
$2000 - $2FFF = $5000 PAGE 6  ; Skiing
$3000 - $3FFF = $5000 PAGE 5  ; Hockey
$4000 - $4FFF = $5000 PAGE D  ; Boxing
$5000 - $5FFF = $5000 PAGE 8  ; Basketball

.

In Windows you can do the first step with a command like this (assuming all files are in the current directory:

.

copy gold.bin/b + skiing.bin/b + hockey.bin/b + boxing.bin/b + bsktball.bin/b gold2.bin
.

In Linux / Mac OS X, the command is similar and slightly simpler:

.

cat gold.bin skiing.bin hockey.bin boxing.bin bsktball.bin > gold2.bin
.

And then just name the config above "gold2.cfg", et voila! You should now have a working Go For The Gold launcher that launches the four games. IIRC, Skiing has a slight race condition issue where occasionally the color stack gets corrupted when you try to launch it. Otherwise, it works pretty well.

thank you for this. I was bummed finding out i lost my complete go for the gold rom
Link to comment
Share on other sites

  • 3 years later...

Based on this information I was trying to see if I could make the Party Line Multi Cart rom since we again received all the pieces if one has Intellivision Lives/Rocks for PC and Lives for Game Cube/PS2. As having those three collections you get all three party line games. From what I can tell Blowout on PS2/Game Cube includes the menu which has options for Space Cadet and Hard Hat (you could also download Blowout from Intellivions.us). Was the Party Line Games actually using the Page Rom structure described above?

If so, I can't figure out how to stitch them together like the How To for Go For the Gold shown above. There is some information I'm missing. I think where I'm lost is how you figured out the paged structure for Go For the Gold and/or WSMB. I'm assuming it's something obvious if you know how to read assembly, or are familiarly with the debugging tools of jzintv. I would appreciate any pointers of where I would need to look to find that information (I'm not looking for the exact answer even though that is quicker) but rather I want to learn how this works. In other words I want to know how to fish and not just be given a fish.

A little background on self so you know my handicap. By trade I'm a software developer, with that said I've only ever programmed using high level languages like Java and Perl, and have never touched assembly until now as I dive into the Intellivision. So I know I have a steep learning curve. And it seemed like understanding how to stitch the Party Line Games into a multi-cart rom would be an easy introduction into Assembly and/or jzintv debug tools.

--The Master

Link to comment
Share on other sites

Based on this information I was trying to see if I could make the Party Line Multi Cart rom since we again received all the pieces if one has Intellivision Lives/Rocks for PC and Lives for Game Cube/PS2. As having those three collections you get all three party line games. From what I can tell Blowout on PS2/Game Cube includes the menu which has options for Space Cadet and Hard Hat (you could also download Blowout from Intellivions.us). Was the Party Line Games actually using the Page Rom structure described above?

 

The "Go For The Gold" title was actually built after the fact. That is, the games it included already existed, were tested and debugged, and were already out in production on their own. Basically, they wanted to package them together with minimal effort.

 

From what I can see in the Blue Sky Rangers' web site, it seems the "Party Line" games were also envisioned (and developed) as stand-alone games to be released in a six-cartridge series, but were then later made candidates for Mattel's new "album cartridge" concept.

 

That suggests to me that they were bundled together in much the same way as the "Go For The Gold" games.

 

The three games were completed and shown with a title screen by Monique Lujan-Bakerink at the January 1984 Consumer Electronic Show. They were well received, but Mattel Electronics closed two weeks later.

 

 

 

If so, I can't figure out how to stitch them together like the How To for Go For the Gold shown above. There is some information I'm missing. I think where I'm lost is how you figured out the paged structure for Go For the Gold and/or WSMB. I'm assuming it's something obvious if you know how to read assembly, or are familiarly with the debugging tools of jzintv. I would appreciate any pointers of where I would need to look to find that information (I'm not looking for the exact answer even though that is quicker) but rather I want to learn how this works. In other words I want to know how to fish and not just be given a fish.

 

If they are all 4K games, they would all fit within the same ROM "segment." A similar technique to what intvnut mentioned above should work:

  • Concatenate the binaries into one larger one
  • Prepare a CFG file declaring the base ROM address and page of each game (in the same order you concatenated them)

Post your work here and others may be able to assist.

 

A little background on self so you know my handicap. By trade I'm a software developer, with that said I've only ever programmed using high level languages like Java and Perl, and have never touched assembly until now as I dive into the Intellivision. So I know I have a steep learning curve. And it seemed like understanding how to stitch the Party Line Games into a multi-cart rom would be an easy introduction into Assembly and/or jzintv debug tools.

 

--The Master

 

Most of us that came here with a programming background never touched Assembly Language before, so you are not alone. Personally, I do not think that reverse-engineering old Mattel games is the best and easiest introduction into that realm. If that's really what you want, there are tutorials and small sample programs included in the "SDK-1600" distribution to guide you -- and of course, there's always posting in this forum to ask your questions.

 

As someone that came to this community in much the same way as you, I would recommend starting directly with making your own game, preferably one with which you are already very familiar, like an old arcade game or even something simple like Pong. Just pick your poison and get to work. ;)

 

The idea is that with an existing and valid game concept, you just need to focus on how to implement it in Assembly Language -- and that's where the tutorials and the sample programs and the community assistance comes in. As your skills mature and you find your way, you'll probably either evolve your game (if you really, really wanted to make it), or discard it and start from scratch with a proper project. In any case, getting started is the hardest part, but never be afraid of starting with a real project just because you may throw it away eventually. That's all part of the process. :)

 

The problem with reverse-engineering a game is that... well, that's a separate skill in itself, and it sort of presupposes an already working knowledge of Assembly Language. There is no source code for those old Mattel games, so you'll have to disassemble them, which means that you won't see what the programmer saw -- you won't see macros and formulas and subroutines and logic functions; no symbols or variable names or any comprehensive structure; you will only see the final operations, instructions, and data that the machine sees after assemblage. It's absurdly hard, especially when you consider the talent and experience that Mattel programmers applied to their programs in order to make them fit into their modest cartridge ROM in whichever ways they could.

 

Besides, old Mattel games used the EXEC (the built-in "operating system" and programming framework of the Intellivision), which is something not readily documented any more, plus home-brew games completely skip it, so no effort is typically put in understanding it.

 

Starting from scratch is almost always easier than that, and eliminates an entire layer of incidental complexity from the task: that of "software-archeology" in reconstructing the intent of the programmer from arcane and often obfuscated machine code. Although your mileage may vary, as they say.

 

Then, of course, there's the IntyBASIC SDK. Why not give that a try first? :)

 

-dZ.

Edited by DZ-Jay
Link to comment
Share on other sites

The party line roms seem to be larger than 4k; between 6k and 7k. I can also say the windows emulator that come with Intellivision lives/rocks for pc doesn't support paging the way jzintv does; not sure about the playstation emulator.

 

Jzintv comes with a disassembler. These old Mattel programs usually made use of code from the Exec rom inside the intellivision. There is a reference guide on programming with the exec here http://www.intellivisionbrasil.com.br/Hardware_Intellivision1.htm. Not sure if the syntax jzintv disassembles is compatible with that documentation. And the disassmbler is designed for analysis not necessarily for reassembly.

Edited by mr_me
Link to comment
Share on other sites

Jzintv comes with a disassembler. These old Mattel programs usually made use of code from the Exec rom inside the intellivision. There is a reference guide on programming with the exec here http://www.intellivisionbrasil.com.br/Hardware_Intellivision1.htm. Not sure if the syntax jzintv disassembles is compatible with that documentation. And the disassmbler is designed for analysis not necessarily for reassembly.

 

The disassembler is not perfect. In my experience, it confuses some data with code, throwing your research off into the weeds. Also, it has no knowledge of the EXEC's symbol table, so unless you can produce one, it will just give you useless labels or absolute addresses.

 

Overall, disassembling a Mattel game and reverse-engineering its source, for the purpose of learning Assembly Language, is to me at least, the wrong approach.

 

If someone went to a mechanic and said, "I know nothing about cars but I want to learn to fix them, so could you please tell me where I could find an engineering schematic from Ford or GM?" I would expect the mechanic to respond with "forget that, if you want to learn to fix cars, then take this course or read this book," rather than just letting the guy shoot himself in the foot without guidance on how to actually do the task he wanted.

 

-dZ.

Link to comment
Share on other sites

If you're analysing an old exec based rom, some of the guys did some work here that might help. http://atariage.com/forums/topic/259109-killer-bees-david-rolfes-trivial-intellivision-game/

 

That copy of your friend the exec has a cpu instruction/command reference. I'm not sure if it's complete or original to the document but the reference material that comes with jzintv looks to be better

 

Like dz-jay said, if your goal is to write new intellivision programs, it's better to look at modern examples than disassembling old rom files.

Link to comment
Share on other sites

I thought the purpose here is to figure out how the the party line rom works.

Specifically, the game selection menu.

Well, I was going by the actual problem that The Master is trying to address:

 

And it seemed like understanding how to stitch the Party Line Games into a multi-cart rom would be an easy introduction into Assembly and/or jzintv debug tools.

 

I was trying to help that goal rather than helping him get lost in the weeds.

 

If he really wants to reverse-engineer the Party Line games, then yeah, he'll have to get some information on the EXEC.

 

dZ.

Link to comment
Share on other sites

 

The "Go For The Gold" title was actually built after the fact. That is, the games it included already existed, were tested and debugged, and were already out in production on their own. Basically, they wanted to package them together with minimal effort.

 

From what I can see in the Blue Sky Rangers' web site, it seems the "Party Line" games were also envisioned (and developed) as stand-alone games to be released in a six-cartridge series, but were then later made candidates for Mattel's new "album cartridge" concept.

 

That suggests to me that they were bundled together in much the same way as the "Go For The Gold" games.

 

If they are all 4K games, they would all fit within the same ROM "segment." A similar technique to what intvnut mentioned above should work:

  • Concatenate the binaries into one larger one
  • Prepare a CFG file declaring the base ROM address and page of each game (in the same order you concatenated them)

Post your work here and others may be able to assist.

-dZ.

Yes I had read that same info which is why I thought I could stich the roms together using cat and then writing a config file just like Go For the Gold. The furtherist I've gotten with that approach is the game boots with the initial animated splash screen. But once I hit any direction on the direction pad the game crashes. Which means I don't have the Page Address correct. Here are two different config files I've created (one which is pretty much exactly the same as Go For the Gold, and one where I thought I was increase the Page memory space. But I don't thin k the paged memory space is actually increasing. My assumption is these games need 16k in each page.

 

[mapping]
$0000 - $0FFF = $5000 PAGE 0
$1000 - $1FFF = $6000
$2000 - $2FFF = $5000 PAGE 6  ; Blow Out 
$3000 - $3FFF = $5000 PAGE 5  ; Space Cadet 
$4000 - $4FFF = $5000 PAGE D  ; Hard Hat

[mapping]
$0000 - $0FFF = $5000 PAGE 0
$1000 - $2FFF = $8000
$3000 - $6FFF = $5000 PAGE 6  ; Blow Out
$7000 - $AFFF = $5000 PAGE 5  ; Space Cadet
$B000 - $EFFF = $5000 page D  ; Hard Hat

If I do need to increase the Page memory space My first main miss understanding with the config files is how to allocate that extra space for each page. As the three Party Line Game ROMs are larger then the Individual Go For the Gold Game. Thus when the Party Line games are merged it's rom size is the same size as the Go For the Gold Rom.

 

To clarify why I think this little project is smaller then going down creating a new game from scratch is I would like to think, adding the Page ROM config settings is closer to replacing hoses on your car engine. You don't necessarily need to learn all about the engine details other learning what type of hose you need and what fasteners you need to add the hoses up in the correct way so the car will run.

But I realize that often times when you have just enough knowledge of a subject to be dangerous we as humans tend to assume some new challenge in that subject is much simpler then it really is. Case in point a professor of software engineering, in either the 60s or 70s, assigned a summer assignment to his top students for them to write a program that could differentiate between different animals in photos, thinking his students and he could solve it in a couple of weeks. it's now 50+ years later and we still haven't solved that problem yet though getting much closer.

 

 

Let me see if I can restated my core questions in a clearer manner, as I think I might have lead everyone done a different path then I was thinking I needed to look for the solution to "The Problem":

 

Are there no simple patterns to look for in the dis-ambled code to figure out where the code expects the paged memory maps (which once found would allow you to make the diagrams intvnut posted on Go For the GOld and WSMB)?

Or do you can you use the jzintv debugger to reveal where it expects those maps to exist as there are no consistent pattern in disassembled code that one cloud look for?

 

If it really does require understanding how to program in assembly in order to figure out what needs to be placed in the config file. Then I agree with DZ-Jay that it would be a better use of my time to work on my own game to learn how it works. IN which case I would start with IntyBasic Instead.

 

--The Master

 

 

 

Edited by The Master
Link to comment
Share on other sites

I guess I don't understand your ultimate goal. Your other post suggested that you were only doing the page ROM thing in order to learn Assembly Language and the tools, presumably for the purpose of programming games.

Now it seems that you were looking to learn the tools and Assembly for the purpose of stitching the Party Line ROMs together.

So here's my suggestion:

  • If you want to stitch together the ROMs , then yeah we can help you figure that out.
  • If you wish to figure out the Party Line (or any Mattel) games to perhaps hack them and modify them, or just for curiosity's sake, then we can help you with that also, but you will need to learn about the EXEC, the disassembler, provide a symbol table for EXEC entry points and variables (I believe I have one handy from a similar project), and maybe learn a bit of assembly language.
  • If you want to learn how to make Intellivision home-brewed games, then forget all of the above because they wont help, and either pick up IntyBASIC (compiled BASIC) or the SDK-1600 (assembly). Home-brewed games do not use any of the EXEC stuff and access the hardware directly.

Either way, we're here to help. :)

dZ.

Link to comment
Share on other sites

Yes I had read that same info which is why I thought I could stich the roms together using cat and then writing a config file just like Go For the Gold. The furtherist I've gotten with that approach is the game boots with the initial animated splash screen. But once I hit any direction on the direction pad the game crashes. Which means I don't have the Page Address correct. Here are two different config files I've created (one which is pretty much exactly the same as Go For the Gold, and one where I thought I was increase the Page memory space. But I don't thin k the paged memory space is actually increasing. My assumption is these games need 16k in each page.

 

[mapping]
$0000 - $0FFF = $5000 PAGE 0
$1000 - $1FFF = $6000
$2000 - $2FFF = $5000 PAGE 6  ; Blow Out 
$3000 - $3FFF = $5000 PAGE 5  ; Space Cadet 
$4000 - $4FFF = $5000 PAGE D  ; Hard Hat

[mapping]
$0000 - $0FFF = $5000 PAGE 0
$1000 - $2FFF = $8000
$3000 - $6FFF = $5000 PAGE 6  ; Blow Out
$7000 - $AFFF = $5000 PAGE 5  ; Space Cadet
$B000 - $EFFF = $5000 page D  ; Hard Hat

If I do need to increase the Page memory space My first main miss understanding with the config files is how to allocate that extra space for each page. As the three Party Line Game ROMs are larger then the Individual Go For the Gold Game. Thus when the Party Line games are merged it's rom size is the same size as the Go For the Gold Rom.

 

 

A couple of problem i see with your config file. Blow out resides in rom at $0000-$1ffff and $1000 is mapped to $d000. If you change that mapping then I think you break the party line menu. Blow out is 8k including the title screen and menu, if you append the other two rom files, they will be at $2000 and $4000 on the cartridge.

 

Currently if you select hard hat or space cadet in the menu, blow out starts. Something tells me bank paging hasn't been set up in this program. If it were setup I think the config file might look something like this. And I'm guessing what the page numbers might be, but that should be found in the program code.

 

[mapping]

$0000 - $0FFF = $5000 PAGE 0

$1000 - $1FFF = $D000

$2000 - $2FFF = $5000 PAGE 1

$3000 - $3FFF = $6000 PAGE 1

$4000 - $4FFF = $5000 PAGE 2

$5000 - $5FFF = $6000 PAGE 2

 

For me, unless somebody gives us the answer, you'd have to analyse the code and figure out what the menu is doing. Bank paging wouldn't be part of the exec system so you won't find it documented there. There is a description on how this type of bank paging works at the link below which should help finding it in the program code.

 

http://atariage.com/forums/topic/230132-intellivision-rom-bankswitching-cartridge-ram-questions/?p=3081037

Link to comment
Share on other sites

DZ-Jay you do understand my ultimate goal quite well with list you called out below, in the sense that I really want to do everything in your list of my goals. However, the goal that I wanted to focus on in this specific thread which got lost in my initial post due to my scattered phrasing of my main questions, was that I only wanted to focus on bullet point 1, figure out how to stitch The Party Line Games together assuming they actually used Page Flipping like Go for the Gold.

In summary the main question I was looking to have answered was where I needed to start my search for figuring out which pages the Party Line Games are expected to live in. Would I find that answer only by disassembling the code or can it be found using the debugger tools in jzintv emulator? Is there another way to figure out that same information that is potentially easier then disassembling the code or using the jzintv debugger?

 

I guess I don't understand your ultimate goal. Your other post suggested that you were only doing the page ROM thing in order to learn Assembly Language and the tools, presumably for the purpose of programming games.

Now it seems that you were looking to learn the tools and Assembly for the purpose of stitching the Party Line ROMs together.

So here's my suggestion:
* If you want to stitch together the ROMs , then yeah we can help you figure that out.

* If you wish to figure out the Party Line (or any Mattel) games to perhaps hack them and modify them, or just for curiosity's sake, then we can help you with that also, but you will need to learn about the EXEC, the disassembler, provide a symbol table for EXEC entry points and variables (I believe I have one handy from a similar project), and maybe learn a bit of assembly language.

* If you want to learn how to make Intellivision home-brewed games, then forget all of the above because they wont help, and either pick up IntyBASIC (compiled BASIC) or the SDK-1600 (assembly). Home-brewed games do not use any of the EXEC stuff and access the hardware directly.

Either way, we're here to help. :)

dZ.



Hi mr_me,
How did you figure out that blowout is only 8k including the title screen? all the ROM dumps I have are 16k in file size, which I thought would mean it's a 16k ROM. As mater of fact all the Party Line Games are 16k in file size. With that said I took your suggested cfg and modified it and now have both Blowout and Space Cadet working. However I must not be understanding how the Memory ranges map to the specific blocks. My understanding of $0000 - $0FFF = $5000 means the data for that portion should be in the data range of $0000 - $0FFF if the bin/rom was looked at in a hex editor like bless.

What's weird is I had to change the way I concatenated the files so that my join command changes from:

 

'cat Party-Line-Blowout.bin Party_Line-Space_Cadet.itv Party_Line-Hard_Hat.itv > Party_Line.bin'

To this:

 

'cat Party-Line-Blowout.bin Party_Line-Hard_Hat.itv Party_Line-Space_Cadet.itv > Party_Line.bin'

Here is my config file:

[mapping]
$0000 - $0FFF = $5000 PAGE 0
$1000 - $1FFF = $D000
$4000 - $6FFF = $5000 PAGE 1  ; Space Cadet 
$7000 - $9FFF = $D000 PAGE F  ; Hard Hat 

 

A couple of problem i see with your config file. Blow out resides in rom at $0000-$1ffff and $1000 is mapped to $d000. If you change that mapping then I think you break the party line menu. Blow out is 8k including the title screen and menu, if you append the other two rom files, they will be at $2000 and $4000 on the cartridge.

 

Currently if you select hard hat or space cadet in the menu, blow out starts. Something tells me bank paging hasn't been set up in this program. If it were setup I think the config file might look something like this. And I'm guessing what the page numbers might be, but that should be found in the program code.

 

[mapping]
$0000 - $0FFF = $5000 PAGE 0
$1000 - $1FFF = $D000
$2000 - $2FFF = $5000 PAGE 1
$3000 - $3FFF = $6000 PAGE 1
$4000 - $4FFF = $5000 PAGE 2
$5000 - $5FFF = $6000 PAGE 2

 

For me, unless somebody gives us the answer, you'd have to analyse the code and figure out what the menu is doing. Bank paging wouldn't be part of the exec system so you won't find it documented there. There is a description on how this type of bank paging works at the link below which should help finding it in the program code.

 

http://atariage.com/forums/topic/230132-intellivision-rom-bankswitching-cartridge-ram-questions/?p=3081037

Link to comment
Share on other sites

 

DZ-Jay you do understand my ultimate goal quite well with list you called out below, in the sense that I really want to do everything in your list of my goals. However, the goal that I wanted to focus on in this specific thread which got lost in my initial post due to my scattered phrasing of my main questions, was that I only wanted to focus on bullet point 1, figure out how to stitch The Party Line Games together assuming they actually used Page Flipping like Go for the Gold.

 

In summary the main question I was looking to have answered was where I needed to start my search for figuring out which pages the Party Line Games are expected to live in. Would I find that answer only by disassembling the code or can it be found using the debugger tools in jzintv emulator? Is there another way to figure out that same information that is potentially easier then disassembling the code or using the jzintv debugger?

 

 

 

Hi mr_me,

How did you figure out that blowout is only 8k including the title screen? all the ROM dumps I have are 16k in file size, which I thought would mean it's a 16k ROM. As mater of fact all the Party Line Games are 16k in file size. With that said I took your suggested cfg and modified it and now have both Blowout and Space Cadet working. However I must not be understanding how the Memory ranges map to the specific blocks. My understanding of $0000 - $0FFF = $5000 means the data for that portion should be in the data range of $0000 - $0FFF if the bin/rom was looked at in a hex editor like bless.

 

What's weird is I had to change the way I concatenated the files so that my join command changes from:

 

'cat Party-Line-Blowout.bin Party_Line-Space_Cadet.itv Party_Line-Hard_Hat.itv > Party_Line.bin'

To this:

 

'cat Party-Line-Blowout.bin Party_Line-Hard_Hat.itv Party_Line-Space_Cadet.itv > Party_Line.bin'

 

Here is my config file:

 

[mapping]
$0000 - $0FFF = $5000 PAGE 0
$1000 - $1FFF = $D000
$4000 - $6FFF = $5000 PAGE 1  ; Space Cadet 
$7000 - $9FFF = $D000 PAGE F  ; Hard Hat 

 

You should take the memory addresses from the original CFG files of each game. That range should tell you the game size and should inform which segments to use for bank-switching.

 

Is this a case of confusion between 16 kilobytes on the disk and 8 kilowords in the memory, since the Intellivision is a 16-bit system?

 

In that last comment, yes. The 16K file size represents an 8K (words, not bytes) ROM size, in Intellivision parlance.

 

-dZ.

Link to comment
Share on other sites

So what I found is that the blow out rom file on intellivision.us is different than the one on the intellivisionlives playstation cd. I was using the one on the playstation cd and it always starts blow out no matter what I select in the menu. When I use blow out from intellivision.us everything works. I found hard hat has an animated title screen with a swinging wrecking ball. Here's the config file I used. And setting up separate banks for $6000 is not necessary, I guess it can bank 8k.

 

[mapping]

$0000 - $0FFF = $5000 PAGE 0

$1000 - $1FFF = $D000

$2000 - $3FFF = $5000 PAGE 1

$4000 - $5FFF = $5000 PAGE 2

 

Here's a couple of screenshots:

post-43287-0-14270200-1536678712.png

post-43287-0-90804400-1536678721.png

Edited by mr_me
Link to comment
Share on other sites

Thanks everyone for your help as I can see where some of my trip ups have been. With that said I'm still a bit fuzzy on how much I understand what I've been told thus far.

Thus, I still have a couple of questions with my assumptions of what has been stated, to make sure I'm not holding to any new falsehoods of my own making that will get me into trouble later.

The Files size of the dumped ROM is not the actually size of the game's ROM size (which on this form calls "kiloword size" when loaded into the television memory). The best way to figure out a games kiloword size is to use the Memory map values in the various Intellivision config files posted in another thread on atariage.

With that said pattern wise it seems there is a direct correlation to ROM file dump size and actual in game kiloword size. That is the files size on disk of a dumped ROM image appears to always be 2x the Game's kiloword size. I'm I correct to assume this? Or is there any of the original 127 intelivision and/or new Homebrew games that don't follow the, 2x kilword size = Dump ROM file size on disk, pattern.

 

Based on my testing with changing page numbers in the config file it appears that the games only work if we use page 0, 1 and 2. Short of lucky guesses is there a way we can figure out which page # they are expected to live at? Meaning is there something in jzintv debugging tools and/or easily discovered pattern wise in the dissembled assembly code that would tell us which pages it expects the games to live in?

--The Master

 

Link to comment
Share on other sites

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.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...