the official Channel F thread!

[3DMAZE]

8 minutes ago, e5frog said:

Swapping palette mid screen is a new fault to me...

 

Damn, if anyone'd know something about this it'd be you. Thanks for taking a look anyway! I'll probably resocket / clean the IC legs and see what happens. It's a version 2 unfortunately, so I'm hoping the custom ICs aren't busted. Oh well, it's only my backup unit at the end of the day

[Mikebloke]

7 hours ago, Hwlngmad said:

Great stuff and keep up the great work.

Thank you!

47 minutes ago, 3DMAZE said:

 

Finally got the damn thing to run, so now I have a working Videocart (that can be flashed) made from all new parts! @Mikebloke I hope you don't mind me using your boxing game to test my Videocart on a real Channel F. I thought it'd be cool to get some homebrew running. Also tested it with CCtro from the wiki. You can ignore any graphical glitches. I have two Channel Fs and my fully working one is currently disassembled, so I'm using the other one that's in need of repairs*. The games occasionally restart or glitch out on boot but pressing on the cartridge itself or reinserting it seems to fix it so it's most likely the janky Channel F. I'll be doing a lot more testing anyways.

 

Once I get this hardcoded version working satisfactorily I'll move on to making it work with an SD card. I'll probably do a hardcoded filename first, then move on to the far more difficult part of making a hot patching multi-menu (may God have mercy on my soul). I've never programmed Channel F games before so it'll be a bit of a learning curve.

 

* Speaking of repairs, anyone seen this before. It starts off with normal graphics, but they slowly get "eaten" starting from the right, leaving the screen in black or white. Possibly a bad socket/joint being affected by the Channel F heating up as it runs?

 

Apologies for the wall of text, lol. Any advice on repairs / how I'm going about this are always appreciated!

 

 

 

 

 

Wow, thanks for trying my game with it, I was going to say, try it with roms that we know definitely work on console as well to be sure... but it looks like its a unique fault to your console. I do get pixel artifacts on mine, where random pixels will go a different colour (but refreshes fine when the pixel changes) - perhaps this is something similar. Its interesting that green doesn't seem to be effected, but red and blue are. I wonder if light green + light blue are the same? My uneducated guess is that there is some fault with recognising what value it should be and displaying another instead - again green showing up properly as green and each line being slightly different is certainly unique. Could that be something to do with the electrical current going through those parts wrong and changing/manipulating/confusing the value somehow? I'm wondering if this is why it progressively goes left too - obviously the screen updates from left to right, top to bottom, as the system warms up, is it getting too warm? Is the side of the VRAM that keeps the right side of the screen pixels next to anything that could be causing it to get too warm? You can tell hardware isn't my thing!

 

Also sign me up for a SD card cart when its done... I know there aren't a lot of people developing for it, but I think the chance to see and feel it on a real console is a big bonus over developing for emulators.

 

Already working on another game, a night rider like racer, got the graphics mostly in, just need to code scoring and game over and that should be another demo out soon.

[e5frog]

On 4/13/2022 at 1:09 AM, Mikebloke said:

Not sure about the hitting other fists... I wanted to maybe have a sound for hitting other boxers gloves, so might be able to sort it out when I do that.

 

I've tried a few programs, MS paint, Graphics Gale, BYOND and a couple of others. I can sort of get it working in Graphics Gale I think but it adds an extra header that I need to delete - except even then it doesn't appear right. MS Paint is a problem because it wants to decide my colours for me... I've tried a few things but it just keeps setting any other colour (for green and red on Channel F) to blue!

 

 

This hitting of fists glitch seem to have been fixed. Looks really good now, not a bunch of flicker.

 

 

 

It seems all 16 color BMP images from MS Paint (on the versions I tested) are averaged into the 16 safe "Windows colors":
https://thestarman.pcministry.com/RGB/16WinColorT.html  (scroll down to "The 16 Windows colors")
They look like this: 

 
Index and color codes:

0 000000 black [black]

1 800000 dark red [blue]

2 008000 dark green [green]

3 808000 dark yellow [red]

4 000080 dark blue [lt green]

... etc. there's C0C0C0 for grey and the others use FF for the color triplets. 

 

Which means you need to use wonky colors (dark red, dark green, dark yellow) to interpret the colors correctly...  with MS Paint 16 color BMP.

So a solution for MS Paint users would be to grab the closest looking colors in the index for drawing, there's only four colors, the rest is backgrounds.

Like this (upper "normal", lower windows safe colors): 

 

I'd probably just use black/white/red/green/blue/grey if drawing in MS Paint. 

I edited the conversion program to suit this color index, the conversion should now work fine. 

Indexes 9, A, C and E are used for red, green, blue, white and the others are background. 

 

Send me an e-mail and I'll see if I can get it past gmail filters. If it works for you I'll upload it to veswiki.com.

Zipping with password and changing the name to end with .bin usually works - in Messenger the .bin is usually enough. 

[Mikebloke]

22 minutes ago, e5frog said:

 

This hitting of fists glitch seem to have been fixed. Looks really good now, not a bunch of flicker.

 

Send me an e-mail and I'll see if I can get it past gmail filters. If it works for you I'll upload it to veswiki.com.

Zipping with password and changing the name to end with .bin usually works - in Messenger the .bin is usually enough. 

Actually I think there is still a minor error when blue boxer is punching and red boxer has moved/punched in its range - I think its an easy fix next time I check code though.

 

Thanks I will send you an email, I think its mostly MS paints fault, I think the old 98/XP etc version does convert their colour palette correctly when switching to 16 colour bitmap, but in the most "modern" version this only seems to happen when saving as monochrome - but I'll give it a go and see if it works.

[3DMAZE]

On 4/13/2022 at 7:51 PM, Mikebloke said:

Wow, thanks for trying my game with it, I was going to say, try it with roms that we know definitely work on console as well to be sure... but it looks like its a unique fault to your console. I do get pixel artifacts on mine, where random pixels will go a different colour (but refreshes fine when the pixel changes) - perhaps this is something similar. Its interesting that green doesn't seem to be effected, but red and blue are. I wonder if light green + light blue are the same? My uneducated guess is that there is some fault with recognising what value it should be and displaying another instead - again green showing up properly as green and each line being slightly different is certainly unique. Could that be something to do with the electrical current going through those parts wrong and changing/manipulating/confusing the value somehow? I'm wondering if this is why it progressively goes left too - obviously the screen updates from left to right, top to bottom, as the system warms up, is it getting too warm? Is the side of the VRAM that keeps the right side of the screen pixels next to anything that could be causing it to get too warm? You can tell hardware isn't my thing!

 

Also sign me up for a SD card cart when its done... I know there aren't a lot of people developing for it, but I think the chance to see and feel it on a real console is a big bonus over developing for emulators.

 

Glad you liked it! It does the same thing with real Videocarts and has always been like this. Lots of good suggestions! I'll try and do more research on how the Channel F handles colors, as you've got a point about it not changing green. My multimeter should be able to check for weird voltages when I open it up. The 4 ICs that make up VRAM on the Channel F are laid out in interlaced vertical columns with one pair doing the odd and the other handling even lines. Normally I'd expect some sort of pattern for VRAM issues. What I'm getting is just weird. But hey, at least it runs games fine. I'm a hardware noob too, so I wouldn't even know where to start if it just didn't turn on. I'll figure it out eventually I'm sure   

 

Also got a video of it so you can see what it looks like:

 

 

 

In regards to the SD flashcart, would you be interested in an early discounted version once I get all official games supported(excluding 10)? It would be entirely functional at that point, though it would lack a multimenu so you'd only be able to have 1 game on the SD card at a time. It probably wouldn't have a fancy sticker/box/manual/case either. It should have the SRAM & LED features though. I'll make a video showcasing it once it gets to that point anyway.

 

For the finished flashcart, I'd like to have (any suggestions welcome! )

• support for 2K of 8-bit SRAM(at 0x2800)
• maybe a programmable LED like the chess cart?
• support for Videocart 10 (I think that's the only one that had special chips?)
• support for all official games
• a multimenu to browse the SD card
• a fancy sticker/box/manual/case to make it look good (just for fun!)
• support for timer interrupts / user interrupts (basically a copy of the 3853 ports)
• the ability to run solely off the Channel F's power (aka without a micro USB cable)

If your happy to wait it hopefully should be done around summer time. Most of those features are fairly easy to implement, but the multimenu will take a while as it has to do some interesting things like rewrite its own code depending on what's on the SD card

Edited April 16, 2022 by 3DMAZE

[Mikebloke]

6 hours ago, 3DMAZE said:

 

Glad you liked it! It does the same thing with real Videocarts and has always been like this. Lots of good suggestions! I'll try and do more research on how the Channel F handles colors, as you've got a point about it not changing green. My multimeter should be able to check for weird voltages when I open it up. The 4 ICs that make up VRAM on the Channel F are laid out in interlaced vertical columns with one pair doing the odd and the other handling even lines. Normally I'd expect some sort of pattern for VRAM issues. What I'm getting is just weird. But hey, at least it runs games fine. I'm a hardware noob too, so I wouldn't even know where to start if it just didn't turn on. I'll figure it out eventually I'm sure   

 

Also got a video of it so you can see what it looks like:

 

 

 

In regards to the SD flashcart, would you be interested in an early discounted version once I get all official games supported(excluding 10)? It would be entirely functional at that point, though it would lack a multimenu so you'd only be able to have 1 game on the SD card at a time. It probably wouldn't have a fancy sticker/box/manual/case either. It should have the SRAM & LED features though. I'll make a video showcasing it once it gets to that point anyway.

 

For the finished flashcart, I'd like to have (any suggestions welcome! )

• support for 2K of 8-bit SRAM(at 0x2800)
• maybe a programmable LED like the chess cart?
• support for Videocart 10 (I think that's the only one that had special chips?)
• support for all official games
• a multimenu to browse the SD card
• a fancy sticker/box/manual/case to make it look good (just for fun!)
• support for timer interrupts / user interrupts (basically a copy of the 3853 ports)
• the ability to run solely off the Channel F's power (aka without a micro USB cable)

If your happy to wait it hopefully should be done around summer time. Most of those features are fairly easy to implement, but the multimenu will take a while as it has to do some interesting things like rewrite its own code depending on what's on the SD card

That is interesting about the video, the encroaching black and white appears to happen at graphic refresh (which makes sense) even though the refresh is not covering any of those specific pixels on the screen. If you try v2 or v3, does it progressively turn back and white on its own due to the timer updating or is it only when there is an input with one of the controllers? If its input on the controller that causes it, perhaps its not directly caused at VRAM after all.

 

Relating to the SD flashcart - I'm about to move anytime in the next week/month hopefully possibly maybe probably - so there is no rush for a super early version... but if you need a guinea pig to test it on a different system I am definitely up for it - I am UK based though with a UK Grandstand model. I don't think there is a super lot different between the two regions from a technical point of view other than power: but not sure if there is any power difference in terms of US and European models and if that would effect its use when not using external power.

 

I could possibly grab the early version and then get the full version too when its done too. Its exciting stuff to think we might soon have a full solution for running homebrew games on the system! I think although its great we have the occasional homebrew cart from salvaged old carts - it would be nice to preserve the stock we have left. It could mean selling digital copies of games might be more viable too - I'd be up for paying for existing developers stuff - hopefully I'll get to the point where I feel its justifiable for my own stuff as well! Boxing is near that point I think, got some of those graphical things to fix with punching - want to add an additional mode as well to it... possibly even 1 Player mode. Its getting there.

 

Regarding carts, did checkers not have additional chips as well? Maybe e5frog can help with that - I might be getting it mixed up with the 1292 machine which had a few games with extra RAM like the hobby module, draughts (checkers), backgammon and chess.

[3DMAZE]

On 4/16/2022 at 8:03 AM, Mikebloke said:

That is interesting about the video, the encroaching black and white appears to happen at graphic refresh (which makes sense) even though the refresh is not covering any of those specific pixels on the screen. If you try v2 or v3, does it progressively turn back and white on its own due to the timer updating or is it only when there is an input with one of the controllers? If its input on the controller that causes it, perhaps its not directly caused at VRAM after all.

 

Relating to the SD flashcart - I'm about to move anytime in the next week/month hopefully possibly maybe probably - so there is no rush for a super early version... but if you need a guinea pig to test it on a different system I am definitely up for it - I am UK based though with a UK Grandstand model. I don't think there is a super lot different between the two regions from a technical point of view other than power: but not sure if there is any power difference in terms of US and European models and if that would effect its use when not using external power.

 

I could possibly grab the early version and then get the full version too when its done too. Its exciting stuff to think we might soon have a full solution for running homebrew games on the system! I think although its great we have the occasional homebrew cart from salvaged old carts - it would be nice to preserve the stock we have left. It could mean selling digital copies of games might be more viable too - I'd be up for paying for existing developers stuff - hopefully I'll get to the point where I feel its justifiable for my own stuff as well! Boxing is near that point I think, got some of those graphical things to fix with punching - want to add an additional mode as well to it... possibly even 1 Player mode. Its getting there.

 

Regarding carts, did checkers not have additional chips as well? Maybe e5frog can help with that - I might be getting it mixed up with the 1292 machine which had a few games with extra RAM like the hobby module, draughts (checkers), backgammon and chess.

 

Unfortunately, the screen still gets eaten even if I don't touch the controls. Same if I don't put a cartridge in and just leave it on the built-in game select menu. I'll clean all the IC legs and get back to you. I'm just being lazy atm as it's a hassle to disassemble, compared to an Atari 2600 for example.

 

Yeah, that's what motivated me in the first place! I know some Videocarts aren't exactly rare, but I still feel bad about recycling working ones. Having one made from entirely new parts was the main goal. The SD card feature is just the cherry on top. As far as being a sort of beta tester for the early version goes, that could work. I still need to add more features and do more testing before I'm comfortable with its quality, which'll take some time anyway. I'll keep ya posted when I get to that point!

 

It'd be cool to see folks selling their own channel F games! Hopefully that could incentivize more development. itch.io seems to be the place for that sort of thing. At least, I've seen folks selling modern Game Boy / GBA games there.

 

It looks like your right regarding the extra chips! Looking into it more: Checkers(22, 74LS02 NOR), Slot Machine(19, 74LS02 NOR), Chess(Saba 20, 8-bit memory-mapped SRAM+LED), Hangman(18, 1-bit port SRAM), and Maze(10, 1-bit port SRAM) all seem to have extra chips. I'm not sure what the extra chip on backgammon is, as I couldn't find a PCB picture. There's probably others as well. I guess I'll just test them all (1-26 + Chess) one at a time to see what breaks, then fix as needed. @e5frog Would you happen to know all the Videocarts that contain extra chips?

Edited April 18, 2022 by 3DMAZE

[e5frog]

@3DMAZE

Looks like there's some broken logic to create that graphics bug. Palettes are set per row, not sure it's even theoretically possible to update the graphics quick and precise enough to change the palette mid row, repeatedly and in sync on a working machine. 

 

For playing Mikeblokes latest creations on a real system - there's nothing more convenient than a flash/card/cart, it's needed and every Channel F owner still using their system will want to have one. 
So what's the plan, are you going to open source it for someone else to bother with it or do you plan on manufacturing and selling? Will you be able to continue to maintain fixes/updates to the firmware or is it a fun one time project?

 

 

Maze (10) and Hangman (18) has RAM handled via the chip port, SABA#20 (Schach / Super Chess) has the $2800 RAM and LED placed on whichever address/range it is. That's all originals that differs from the "normal". The logic chips on later versions are of no importance, possibly there because a memory interface and plain rom chips were used for the later ones and an inverter was needed for /CE... or so. 

 

Regarding homebrews, if RAM is used it's on $2800, there's no other oddities (yet) - simply because it was emulated in MESS/MAME (RAM only at that position) - also makes it easier for the Multi-Cart. IIRC RAM can be used in different areas as well in MESS/MAME now-a-days... which can be bad - if there's a bug writing to a ROM area that isn't write protected.

 

Now that we have a second working "all new parts, modern" alternative (the other guy did it the same way)... 

If/when introducing flash/memory card why not make a proper file format for the binary files, with an information header, like for example the .crt format for C64.

I use .chf for my own purposes, having .bin-files for 10-15 various reasons easily turns into a mess, I suggest stealing most of the description from .crt... 

 

I'm just throwing something out here:
Start with a 16 byte indicator "CHANNEL F CART  " to show that it's really a .chf-file

A value that tells the offset for where the first data byte starts.

Hardware type (to also cover Multi-Cart with it's latch and possible new types of cartridges)

An area for the name of the cartridge, perhaps more than the 32 bytes in .crt files, a termination character could be an idea - and (as the header) not a fixed size.

 

Where the data starts there is a block/chip header for each packet, 16 bytes long:

Starts with indicator: "CHIP", then a number for the total length of the data that follows after the header (can be anything really 1/2/4/8/16/32/64/128/256/512/1024/2048/.../32KiB), the address where this packet goes, what is the type of chip for this chip packet: FLASH (which is supposed to be saved in the .chf file)/ROM/RAM, start address for this chip packet.

Then data for this chip packet starts after the 16 byte chip packet header. 

 

It would be much possible to use the entire .crt format and just skip everything not used. But for the Channel F it might not need to be such a large "minimum header" as the .crt has. 

 

Here's a description:
http://unusedino.de/ec64/technical/formats/crt.html

After we have agreed on something and it's implemented for real we can THEN ask the MESS/MAME people to add it - which would be very helpful. 

 

As the header isn't fixed any data could be stuffed in there, images, pdf - whatever. 

 

I was planning a 62KiB ROM/62KiB RAM cart with latch available to setup and change configuration when running, perhaps even more of each. 

Such a cart dump would need that type of a hardware description to be covered by a card-cartridge. Imagine latching, writing in RAM, latch to ROM and continue from there etc etc

 

 

Anyway, the new high tech mini-computer in the cartridge would scan headers in the .chf-files for the titles and insert these into a pre-programmed menu ROM as a simple list (like it is now). It would pick up for example "VIDEOCART-10*MAZE" from a header where * indicates "new row" and @ is the end of the string and a number at the end to point at an index for where the data is on the card/file. 

Writes to $0000-$07FF could be used to interface the Channel F to the cartridge selection system. For example if Maze is selected it writes index $23 (because it was the 35th .chf-file found) to $0666 and the selection system picks it up and feeds the Videocart-10 binary data to whatever memory is used. 

After writing the index value the menu the program jumps to a loop stored in RAM that gives enough time to shuffle data/setup the cartridge before it cleans up and resets (jumps to $0000) or maybe loop and wait for a ready signal.

 

 

I haven't given it much thought.

 

[3DMAZE]

@e5frog

 

The plan is to do both those things, even if they don't necessarily go hand in hand. Technically the firmware is up publically on GitHub right now, but it's an older version and I'd like to clean it up before linking it. The idea being that if you have the skills, you can make your own, but if not, or if you don't have the time, I can manufacture and ship it for a cost. I do plan on keeping up with development/fixes and the Channel F community in general! In fact, I'd like to develop a few games myself once it's done. And being open source, someone can always fork the firmware if I drop of the face of the earth, or make a pull request if they've made a new feature.

 

That's a good point regarding file formats! Currently my flashcart just copies the first .bin file it finds from the SD card directly into memory. Going off of your format, what about something like this (the hex data is random and just for illustration purposes)? This is just a base of course, more thought would be put into the final version. It doesn't implement the chip idea, but that's mostly because I didn't really get it when reading the link, haha. A zip file would probably work fine for storing multiple files?

 

• Magic number (9 bytes) = used to detect a valid file, "CHANNEL F"
• File Format Version (2 bytes) = allows the header to be changed/updated in future
• Header length / ROM start  (2 bytes) = redundant for now, but would allow for future versions to expand the header
• Hardware type = describes specific hardware (I could probably just include the port RAM/timer/interrupts in all of these since the ports shouldn't interfere with anything not using them). This can be expanded if new cartridge types are created

  •   $0000 ROM
      $0001 ROM + LED
      $0002 ROM + 2K RAM @ $2800
      $0003 ROM + 2K RAM @ $2800 + LED
      $0004 Multi-Cart with it's latch
      $0005 ...

     

• Reserved for future use (5 bytes)
• Videocart version (2 bytes) = the game version (e.g. $0003 for boxingv3)
• Videocart name length (1 byte) = allows a name size from 1 - 256 (we add 1 to the byte, as a name size of 0 is pointless)
• Videocart name (1 - 256 bytes)
• Videocart author length (1 byte)= allows an author name size from 1 - 256
• Videocart author (1 - 256 bytes)
• Videocart ROM length (2 bytes) = length of game in bytes (we add 1 to the byte, as a ROM size of 0 is pointless)
• ROM = the ROM data (1 - 64K bytes)

As for the multimenu that's similar to what I was thinking. Since FAT32 can store 65,536 files max in the root directory it would be something like: If we're running the multimenu program, writes to $0001 stores the high address, writes to $0002 stores the low address and signals the 1st core to start the loading process (with the address being the index of the file). Note, in my design the 2nd core is the one handling all Channel F interactions/emulation, so the 1st is free to handle all the not-time-sensitive busy work.

 

I wonder if it would be easier to do that for the titles too. So the multimenu program has a single string (or maybe a 2nd for the author, but that might be too much for the screen) with a single index somewhere on screen (like "VIDEOCART 10*MAZE" and "7/42"). Then to get the next filename, we write anything to $0003, which tells the 1st core to overwrite the string and increment the index. Writing anything to $0004 would get the previous title and decrement the index. The multimenu code could be pretty small at that point. I mention this method because if we allow filenames up to 255 in length (or longer) the list could become too large for the program. In reality no ones going to have hundreds of Channel F games on an SD card anyway, so I'm probably overthinking it.

 

I like the loop idea. The SRAM is separate from the program array and just shadows it depending on whether sramPresent is true or false. So, keeping with the theme, it could look like:

$2800: 0x29, 0x28, 0x00

Which is an infinite loop. When the file is done loading, the 1st core writes a 0 to $2801, which makes the loop jump to $0000. Then it sets sramPresent to true or false depending on the Hardware type along with any other configurations needed while the BIOS is busy clearing registers.

 

[e5frog]

@3DMAZE
Looks good, I think the data should be in packets of a defined sized (and position) per package instead of a size for all ROM, also define type of memory RAM/ROM/NV memory, that way it would cover all combinations and not need a hardware description for every setup. For a certain hardware type it might be difficult to define ROM size, if using bank switching for example. 

It would be nice to fit as much as possible of the cart description in the .chf file and not rely on external hardware descriptions.

Hardware descriptions would cover such as LED(s) at certain position, latches, i/o extensions such as relays/joysticks/networking...

I used Fe-RAM for a couple of Pac-Man carts, such functionality would be neat to have described in the .chf file - even if interesting portions of RAM could be saved in a modern setup. 

 

I would move the reserved bytes to the row after the "magic key" and move the other data to the next row - just for looks.

 

Taking your example, the packet system would reduce hardware descriptions to this:

  $0000 $mmmm RAM on port X 
  $0001 LED @ $3000
  $0002 8-bit control Latch at @ $FFFF
  $0003 ... can't think of any more

 

[3DMAZE]

@e5frog

Ah, I think I get what you mean now. Would something like this work?

• Hardware type (2 bytes) = described below. Mainly used for special registers / banking schemes as they're mutually exclusive. If the type isn't recognized, it just skips the game. Maybe this should be split into two sections? I'll think about it a bit more.
• Packet (16 bytes) = some type of data or hardware
  • Magic number = "CHIP"
  • Total packet length = header + data
  • Chip type = what this data represents, described below
  • Starting load address = the address to place the data
  • Data length = the amount of data
  • Data

 

I've moved LED to the chip type section, as packets can be mixed and matched as desired. The hardware type is unique to the entire file and as such it's options are mutually exclusive. The I/O extensions (joystick/network/relay/real-time-clock) could probably also go into the packet section to allow any cart/combination (like if a game wanted both joysticks and network features). Again, if a packet isn't recognized/supported it can ignore the entire game. Perhaps this could also be split into data packets and hardware packets? Probably unnecessary...

 

Chip types:

• $0000 ROM = read only data
• $0001 RAM = read/write data
• $0002 NV-RAM = The initial save data. Non-volatile
• $0003 LED = writing to this address range will trigger an LED toggle. Only a header, as there's no data with an LED packet.
• $0004 ... 

 

Hardware types:

• $0000 Normal = only LED can overlap with RAM/ROM/NV-RAM. All other packets must have non-overlapping addresses. No special registers
• $0001 Bank Type 1 = 8-bit control Latch present at $FFFF. Packets can overlap, as they will be banked depending on latch settings.
• $0002 Multimenu = special registers $0001 - $0004 are present. Automatically loaded on boot.
• $0003 ...

 

Some Packet Examples:

• Multimenu = Having it on the SD card makes developments/updates easier

  • Hardware Description $0002
    Packets
       ROM $0800 - $2800  // 4K ROM
       RAM $2800 - $3000  // 2K RAM

• Chess

  • Hardware Description $0000
    Packets
       ROM $0800 - $2000  // 6K ROM
       RAM $2800 - $3000  // 2K RAM
       LED $3800 - $4000

• A homebrew game with 6K ROM & 4K RAM (non-contiguous)

  • Hardware Description $0000
    Packets
       ROM $0800 - $1800  // 4K ROM
       RAM $2800 - $3000  // 2K RAM
       ROM $3000 - $3800  // 2K ROM
       RAM $3800 - $4000  // 2K RAM

• A homebrew game with NV-RAM used to save high scores
  • Here I think the .chf file shouldn't be modified, but instead contains the initial high scores when the game is used for the first time. Then the NV-MEM is written back to the SD card as a .sav file similar to how the GBA emulators work. The second time you play, it would see the .sav file and load that instead of the NV-MEM packets data. This way folks can share saves without sending the entire game, share the game without save data, and it prevents the game from being as easily corrupted.
  • I'm wondering how best to emulate NVRAM on the flashcart. The issue is that cutting the power works fine with real NVRAM, but it's not like the Pico can detect it has no power and write to the SD card, since without power it would just die. Looks like the EzFlash ODE flashcart for the GBA uses an FRAM chip, for saves. Then next time the console's restarted it writes it to the SD card. I might be bikeshedding a bit, so I'll leave it for now.

  • Hardware Description $0000
    Packets
         ROM $0800 - $2800  // 8K ROM
       NVRAM $2800 - $3000  // 2K NVRAM

     

Edited April 19, 2022 by 3DMAZE

[3DMAZE]

Another idea would be to get rid of the hardware description, and instead have "Data Packets" (contain data) and "Hardware Packets" (describes hardware, no data), where either one can be memory-mapped(start, size) or port-mapped(port #, size). This is maybe simpler and less confusing. Here's a few random examples of either.

Data Packet Examples

• ROM (memory-mapped)
• NVRAM (memory-mapped)

Hardware Packet Examples

• 8-bit RAM (memory-mapped)   essentially marks an area as R/W
• 1-bit RAM (port-mapped)
• I/O extensions (joystick) (memory-mapped)
• I/O extensions (real-time-clock) (port-mapped)
• LED (memory-mapped)
• 8-bit control Latch present at $FFFF (memory-mapped)
• special multimenu registers $0001 - $0004 (memory-mapped)

It's still more complicated than just ($0000: 3DMAZE Flashcart, $0001: e5frog multicart, $0002: normal) but I agree with you on flexibility and future proofing. I'll do a bit more work on it to see if I can get the best of both worlds, that way I'm not just flooding the thread with random ideas.

Edited April 19, 2022 by 3DMAZE

[e5frog]

On 4/19/2022 at 8:26 PM, 3DMAZE said:

Another idea would be to get rid of the hardware description, and instead have "Data Packets" (contain data) and "Hardware Packets" (describes hardware, no data), where either one can be memory-mapped(start, size) or port-mapped(port #, size). This is maybe simpler and less confusing. Here's a few random examples of either.

Data Packet Examples

• ROM (memory-mapped)
• NVRAM (memory-mapped)

Hardware Packet Examples

• 8-bit RAM (memory-mapped)   essentially marks an area as R/W
• 1-bit RAM (port-mapped)
• I/O extensions (joystick) (memory-mapped)
• I/O extensions (real-time-clock) (port-mapped)
• LED (memory-mapped)
• 8-bit control Latch present at $FFFF (memory-mapped)
• special multimenu registers $0001 - $0004 (memory-mapped)

It's still more complicated than just ($0000: 3DMAZE Flashcart, $0001: e5frog multicart, $0002: normal) but I agree with you on flexibility and future proofing. I'll do a bit more work on it to see if I can get the best of both worlds, that way I'm not just flooding the thread with random ideas.

 

Seems difficult to have a standardized hardware description method in the data-file. IMHO it would be best to keep it out of the cart data. 

I just copied the .crt format as it seemed logical and versatile - has been around for some time now. 

 

If going chronologically:

$0000  just ROM

(any size $0800-$FFFF, would include trimerous)

 

$0001  ROM + port RAM

(Maze and Hangman - there's no others)

 

$0002  ROM + RAM + LED

(each has an address, only Chess cart presently - as  I intentionally skipped it on the Multi's not built from actual Chess carts)

 

$0003  ROM + RAM

(All my carts, started with Pac-Man, memory mapping circuitry is of course needed in the real hardware, the addresses on the CHIP packages will however give that information)

 

If coming up with new hardware a new code is added - if needed.

The LED could be set as ROM at certain address in the .chf description, it's an address you can write to... on/off.

 

 

 

 

Pretend we use the .CRT format straight off, is it enough? 
I think it's too rigid in some parts, like the title of the game and other additional information, our common idea to have length encodings on the block seems more clever than having fixed sizes on some part. 

 

If we can agree on the fileformat, I think we get to decide.

I think the difficult part is to futureproof it - that's where the .CRT format has been good enough. 

 

I will write a description per .CRT standard for New Pac-Man and we can discuss if it's good enough. Apart from the header it would work with some tools already existing as well - like my crt2chip program that strips the extra data and puzzles the data together into .bin files for writing on actual chips. 

[e5frog]

On 4/19/2022 at 7:06 PM, 3DMAZE said:

 

A homebrew game with NV-RAM used to save high scores

• Here I think the .chf file shouldn't be modified, but instead contains the initial high scores when the game is used for the first time. Then the NV-MEM is written back to the SD card as a .sav file similar to how the GBA emulators work. The second time you play, it would see the .sav file and load that instead of the NV-MEM packets data. This way folks can share saves without sending the entire game, share the game without save data, and it prevents the game from being as easily corrupted.
• I'm wondering how best to emulate NVRAM on the flashcart. The issue is that cutting the power works fine with real NVRAM, but it's not like the Pico can detect it has no power and write to the SD card, since without power it would just die. Looks like the EzFlash ODE flashcart for the GBA uses an FRAM chip, for saves. Then next time the console's restarted it writes it to the SD card. I might be bikeshedding a bit, so I'll leave it for now.

•  

@3DFXgamer

Just noticed this part. 

 

The Ultimate II+ for C64 emulates the EasyFlash-format, popular large FlashROM cart as a .crt file. EasyFlash can write to itself to save scores etc - the "U2+" handles this - not like a tape or disk file where you can write protect or not too keep the original (or make a editable copy) but you have to return to the menu and manually save any changes made while you where playing on the "virtual" .crt file - where changes are stored in memory but not in the file itself... 
It's extremely annoying, being able to do the writes directly to the file is super-nice (when using other methods). If you want to write protect the file or play from a copy you're free to do so. 

 

Having the data in the file will allow it to move around to other machines/real carts without separate handling of a save file. I could agree that an addition to the original file could be neat - a CHIP packet that is added last and writes over any data present on that address before.
For a single custom solution a save file is handy, I tend to loose such files myself for emulating other systems so I'm not a fan. The "full computer backup" you can do in emulators are great but if they aren't working in the next version of the emulator they're not worth much (VICE for example). 

 

I would emulate NVRAM on the flash cart as writing directly to a file. System can be shut down at any time so to keep it real it would need to update to a "n-v" storage format at once.

I don't know if there's FlashRAM enough on the mini cpu you have chosen - that could be an option. If power is shut off the data will still be there - and it could be written to a file on the next power up. Saving to a nvram-file could perhaps happen in intervals if it isn't handled immediately. Maybe a large enough cap will allow to hold the voltage up at power off to dump the data to a file on the SD card / USB memory. 

 

I don't have any practical experience, don't have much time to enjoy that part of tinkering - as I have chosen the part of the Channel F cartridge manufacturer, fills every free hour.

 

 

I'll write up a complete file in plain .CRT-format and you can comment on that. 

[3DMAZE]

@e5frog

 

Yeah, I was having trouble figuring out how to add banking with packets. I'll add the hardware type back into the file header as you say. Keeping the hardware description outside the data file does make more sense.

 

As for how hardware type is used, personally I'd prefer to keep it just for banking or anything else that uses packets in a weird way, rather than the fixed ROM / RAM+ROM / ROM+port RAM. That way, if we added a joystick port for example, it wouldn't need multiple new hardware types like ROM+JOY / ROM+RAM+JOY. We could just add the packet and that'd be that. It's a bit more flexible. I also wanted to provide the 3853 ports on the flashcart, which would also need something like ROM+3853 ports / ROM+RAM+3853 ports, etc. if it was fixed.

 

Regarding saves, that's fair enough. For the flashcart, it honestly might be easy enough to just add an FRAM IC. They're not that expensive all things considered. As long as SPI is fast enough it should work fine.

 

I was working on a template for the third iteration to collect our ideas so far. That way they aren't scattered across multiple posts. Most of it was made before your recent post, but I'll wait for your .CRT file before updating it. Anyway, here's the github link:

 

https://github.com/ZX-80/Videocart-Image-Format

Edited April 22, 2022 by 3DMAZE

[e5frog]

@3DMAZE

Here's a version of Pac-Man in the .crt format, unchanged. 

The file has .bmp added to be able to attach it here (don't tell anyone). 

 

Offset      0  1  2  3  4  5  6  7   8  9  A  B  C  D  E  F
00000000   43 48 41 4E 4E 45 4C 20  46 20 20 20 20 20 20 20   CHANNEL F       
00000010   00 00 00 40 01 00 00 01  00 00 00 00 00 00 00 00   ...@............
00000020   50 41 43 2D 4D 41 4E 20  56 49 44 45 4F 43 41 52   PAC-MAN VIDEOCAR
00000030   54 2D 32 37 20 48 4F 4D  45 42 52 45 57 20 20 20   T-27 HOMEBREW   
00000040   43 48 49 50 00 00 20 10  00 00 00 00 08 00 20 00   CHIP.. ....... .
00000050   55 FB 70 B1 B4 B5 B0 64  68 5C 20 3E 67 6F 5C 2A   Uûp±´µ°dh\ >go\*
00000060   2E 21 70 88 88 88 88 88  88 88 88 2A 2E 20 88 1F   .!pˆˆˆˆˆˆˆˆ*. ˆ.
00000070   94 03 90 FF 28 20 BC 2A  2E 00 16 25 48 94 08 16   ”.ÿ( ¼*...%H”..
00000080   25 49 94 03 90 1A 2A 2E  00 20 48 17 20 49 17 70   %I”..*.. H. I.p

 

Here's the original description:

 

 Bytes:$0000-000F - 16-byte cartridge signature  "C64  CARTRIDGE"  (padded
                     with space characters)
         0010-0013 - File header length  ($00000040,  in  high/low  format,
                     calculated from offset $0000). Default value is $40
         0014-0015 - Cartridge version (high/low, presently 01.00)
         0016-0017 - Cartridge hardware type ($0000, high/low)
                       0 - Normal cartridge
                       1 - Action Replay

 

First row is the magic key - header to check if it's the kind of file we want, CHANNEL F (fill spaces) instead of what is written above. 

 

at 0010-0013 we have header length, same as standard CRT here $40, and in the same format (high/low) to keep the standard. 

If more i formation is inserted, the header length is increased and information added perhaps as four byte for length, then data. 
It would allow 4GB headers. So you could in theory fit scans of box, booklet, instructions, video that can be extracted who knows - in the header and still keep the format. 

 

0014-0015 is the cartridge version - it's our first so 0100 [v1.00], I think they mean CRT version and not "cartridge version" - if it's a future proof version there will never be an update. 

 

0016-0017 I have set the cartridge type to 2 as it's a ROM+RAM cartridge, it's a suggestion

 

0: ROM

1: ROM + port RAM

2: ROM+RAM

3: SABA Videoplay 20

4: Multi-Cart

6: Upcoming cartridge types

...

 

The rest of the row is reserved for "future use". C64 specific cartridge settings aren't of interest.

 

$0020 Title 16x2 bytes

 

Then we're in this example at the end of the header, data starts. 

 

CHIP packet

  Bytes:$0000-0003 - Contained ROM signature "CHIP" (note there can be more
                     than one image in a .CRT file)
         0004-0007 - Total packet length ($00002010,  ROM  image  size  and
                     header combined) (high/low format)
         0008-0009 - Chip type
                      0 - ROM
                      1 - RAM, no ROM data
                      2 - Flash ROM
         000A-000B - Bank number ($0000 - normal cartridge)
         000C-000D - Starting load address (high/low format)
         000E-000F - ROM image size in bytes  (high/low  format,  typically
                     $2000 or $4000)
         0010-xxxx - ROM data

 

Nothing changed, it's exactly this. 

Then there's a new CHIP header after first $2000 ROM data:
 

Offset      0  1  2  3  4  5  6  7   8  9  A  B  C  D  E  F
00002050   43 48 49 50 00 00 08 10  00 01 00 00 28 00 08 00   CHIP........(...

This describes packet length $0810, it's RAM it starts at $2800 and is $0800 long. 

It could be filled with any data that you'd want to load into RAM.

In the file it's all 0:s

 

Next CHIP:

Offset      0  1  2  3  4  5  6  7   8  9  A  B  C  D  E  F
00002860   43 48 49 50 00 00 10 10  00 00 00 00 30 00 10 00   CHIP........0...

This is the last piece of ROM, $1010 with CHIP header, set as ROM, starts at $3000, $1000 long.

 

The CHIP pieces doesn't need to be in order.

You could have a new CHIP block that overwrites a former one (saved file with a new RAM CHIP-packet). 

 

Seems to me it could be enough, with the header size option. 

Encoding small or big endian is perhaps a matter of taste, it would be handy to follow the CRT standard even if it's easier for some people with some hardware or application to do it the other way around. 

 

 

 

 

Videocart-27.chf.bmp

[3DMAZE]

@e5frog

 

Cool! I will say though, overall, I don't really see how we benefit from restricting ourselves into following the .crt format so tightly. It's not as if these will be compatible with the CCS64 emulator, and realistically the only programs that will ever use it are MAME and the flashcart. A slightly modified version would be better IMO. If it's an issue with existing scripts, I'd be happy to rewrite them. All that said, I'm not too fussed with what format we decide. As long as it's usable I'm A-okay with it! As such, I've made a few comments below on the .crt format. Otherwise, I think it'll work well enough as you say:

 

Header

• File storage: Images/manuals/videos would be better stored in a zip I think. Everyone's computer can read that format. Re-inventing the wheel and storing multiple files in the game file makes it a bit bloated, and would require everyone to download/install another program on their computer just for extracting those files. I think it should do one thing and do it well (store the game). This isn't a comment on the format itself since there's nothing stopping anyone from doing it. If someone wants to include extra stuff like boxart in the .crt file that's fine. I just don't think it should be encouraged necessarily. A channel F game shouldn't be 4GB in size.

• Updates: Future proofing is important, but it's not the end of the world if we make a version 2.0 after finding out something's not working (once folks have used it for a while). Since only ~2 programs use the format, it wouldn't be that difficult to update. Of course we'll do our best to make sure we don't have to, but updates aren't so bad. And any minor updates can be backwards compatible. That's what the minor version number's for after all.

• Hardware type: I think I made some comments on the hardware type in a post above. Looking at the .crt hardware description, they mostly use it for different banking schemes. I think that would be best for development, as adding any new hardware combinations becomes very tedious. Why have a unique number for every possible hardware combination. Just let the packets say what hardware is used.

• Title section: I liked the idea of making it variable, and including an author/version. Just because the .crt format is limited to 32 characters doesn't mean we have to be. It's 2022 after all, lol

 

Chip packets

• Chip type: Adding more types like NV-RAM or LED works fine. But how will the chip type handle port devices. If their port addresses are fixed it could be in hardware type (though I think that should just be for banking), but then you'd need one for every possible combination, and that gets cumbersome fast. Especially as more are added. I think using the Length & Data area for port addresses as shown in the third iteration works. It's also compatible with (i.e. doesn't change) the .crt format.

• RAM data: I thought about doing this too, but the chip packets represent an actual hardware chip. Since RAM is uninitiated, it shouldn't have data. Yes, a flashcart/emulator could initialize it, but if they're trying to copy real hardware, then they should leave their fake RAM uninitialized at boot. Developers shouldn't rely on RAM being initialized, that way their games could work on real hardware. If a developer wants something like this they can use NV-RAM (which might have been what you meant).

• NV-RAM: On the flashcart, the NV-RAM is a separate chip. I need to know what the game wants so I can choose where to put RAM and to decide how to save it. Thus it need to be a separate chip type.

 

In conclusion, I think the following changes should be made to better suit our needs:

• Header: We should only use hardware type for banking schemes, and the 32-byte title should be changed to the variable title/author one
• Packet: We should add a few more chip types (NV-RAM/LED/any port devices)
• Endianness: To my knowledge, the only modern CPU architectures that practically use big-endian are z/Architecture and OpenRISC. One of those is a giant IBM mainframe, and the other doesn't exist yet. So following big-endian wouldn't be worse for some, it would be worse for everyone. Hence why I think we should choose little-endian.

 

Let me know your thoughts and I'll write up a 4th iteration. Finally, I'd like to say that none of this is meant in a negative tone, if it comes across that way. It's hard to make criticisms in text without sounding like a jerk sometimes. ? Anyway, it's getting late for me so I'll sign off for tonight. Have a good one!

Edited April 24, 2022 by 3DMAZE

[3DMAZE]

Alrighty, it's been about 3 weeks since my last video, so here's a little update on the Flashcart. Life's busy as always, but I've been going through some official games to make sure things work. Also focused on improving the firmware. Mainly refactoring, but support for the regular SRAM & port SRAM was added, so Chess & Videocart 10/18 should work (haven't tested it yet). Here's another demo, this time it's Videocart 15 (I'll pop the hood & fix those video issues one of these days, ha):

 

 

I also tested some more homebrew and discovered an interesting issue. Someone made Channel F music, but when testing it I got the below result. Beautiful! It should sound like: https://www.youtube.com/watch?v=TdagX1gZDIY So I wonder:

• Did it use any special chips? It doesn't appear to use special ports (e.g. 3853 SMI) or SRAM which would cause issues as they weren't implemented at the time of recording
• Is it my version of the Channel F? The plug leads me to believe it's one of those version 1.5s, but maybe the sound's only good in the proper version 2

If it's neither, then it's probably a bug with the firmware that I'll have to track down. If anyone knows anything about these music ROMs I'd appreciate the help, thanks!

 

 

Also, I'll unfortunately be out of the country most of May, so I won't be able to test anything for a bit. I could bring the Channel F with me, but it's a 60 Hz device, and I worry it would break in a 50 Hz country. I can still work on perfecting the firmware / final PCB / case, in the meantime. Once that's done I'll record a proper high quality video showing off all the official games with my working Channel F (so no video issues) and flashcart.

 

@Mikebloke After I've confirmed it works, and barring any major issues, I should be able to offer a beta version or two (if folks want to help test it) early June. This would lack the completed firmware (multimenu, bug fixes, etc.), a nice cartridge sticker, may have PCB issues, and probably won't include the diode for internal power (it runs at ~137mA which is almost certainly fine, but better safe than sorry).

 

I've decided not to do a box, as I'm no artist, and I don't want to delay anything for a piece of cardboard. In short, anything can happen, but I expect to have it all completed late June!

 

[Mikebloke]

Pretty sure the tracker cart has something special in it, but as always, better directed at @e5frog@e5frog!

 

I mean, it's up to you about any beta devices and whether its worth it with such a short lead time between beta and full release if you think its possible in such a short amount of time, if its a genuine case of testing with a different machine and putting it through its paces, then absolutely I'm up for trying it and we can try and iron out any bugs. 

 

Its sounding good regarding full compatibility with existing carts, this will help of course with designing the best possible homebrew for use on real systems. 

[3DMAZE]

Looks like you're right! It seems to use a special banking scheme. Maybe after I get the official games working, and with more info, I could add support for it too. I must have missed this quote from e5frog earlier in the thread:

On 7/8/2021 at 11:41 AM, e5frog said:

Kleeder has an eprom programmer so it's rather easy to swap the FlashROM IC back and forth between console and programmer. Its intended purpose was to use with available music programs so it's just plain ROM and no RAM, it's as simple as it can be. It uses the full address bus with four banks (64KiB x4 - but 2KiB reserved).

 

I'll be thoroughly testing everything, but I think it'd be good to have it field tested too (especially on a different machine), so if you're up for an early version that'd be great! By the bye, how's the Boxing game going?

 

Edited May 7, 2022 by 3DMAZE

[Mikebloke]

16 minutes ago, 3DMAZE said:

Looks like you're right! It seems to use a special banking scheme. Maybe after I get the official games working, and with more info, I could add support for it too. I must have missed this quote from e5frog earlier in the thread:

 

I'll be thoroughly testing everything, but I think it'd be good to have it field tested too (especially on a different machine), so if you're up for an early version that'd be great! By the bye, how's the Boxing game going?

 

OK I'm up for it, I'll get a complete one too though when it's done! 

 

Boxing is still on version 3 download here:

 

Because of the house move I've not touched boxing but did get round to breaking racing the other day might start it again from scratch! 

 

Boxing I think has one or two graphic bugs to fix, nothing gameplay effecting, I want to change the title screen to a selection screen, so the current version would be 'arcade' and then add an additional mode with a stamina bar and possibly a knockout countdown. I think the same stamina feature can be used for both features, so there isn't too much on the screen to worry about. 

 

The other thing I'm considering is a blocking move, this would also take stamina, but less than being hit. Everything else would also take stamina so: moving would take a little, punching takes a bit more, being hit takes the most. When stamina goes down to 0, you fall to the ground. You got ten seconds to get back up your stamina using a combination, perhaps harder the more you fall down. 

 

This feature could then mean additional rounds, playing like a real boxing match, either ending with TKO, KO or a points based win. Perhaps max stamina is limited per round to keep it from going on normally to a full set of rounds? We'll see. 

 

The only other feature I'd be keen to add is single player... Wish me luck on that! 

[e5frog]

@3DMAZE

The music shouldn't sound like that, did you start it the right way (insert cartridge, press reset).
There's nothing special at all about all the music available (Battle of the bits) and I made the Protocart with just an Eprom connected to an SMI, with needed logic and DIP-switches to use the entire eprom. It's just ROM from $0800-FFFF. Same way with all the music using any of the versions of the Sleisza-routines. @kleeder would have loved a flash cart but settled for moving eprom back and forth. 

Even the first generation consoles sounds descent with those routines, the "1.5" has the same chips as Channel F II but in the old shell - so that's a bit cleaner but the method itself tends to give quite a harsh sound and nothing like the monophonic sound of the Football-routine. (which sounds crap on generation 1).

 

Not bringing a "60Hz device" is not a bad choice, the small iron core for 60Hz transformer heats up pretty well (even if using a needed step down transformer) - if you're thinking of the NTSC video - well, it's up to the TV. 

 

I'll be happy to give the flash cart some serious beta-testing, I'll come up with things you didn't even suspect.   
I have a lot of consoles to compare with and test. The super fast Luxor generation 1 (runs at 2MHz), Luxor v2, SABA 1 and 2, Adman Granstand, US pre-Channel F, a couple of loose NTSC boards and a Channel F II...  four ITT Tele-match. I think that's it atm. 

 

You should do a box, even if it's just white or even if it just says "CHANNEL (F)LASH". 
There's always people willing to help with graphics.

 

 

 

Finished eleven circuitboards for Arlasoft Collection today, I feel very productive. 

 

 

 

Edited May 7, 2022 by e5frog

[3DMAZE]

@Mikebloke Sounds like a solid plan. Good luck with the AI in single player mode! Should be fun

 

@e5frog I figured it out! Since most Videocarts don't have a 2^nd data counter (DC), I never wrote one into the firmware. The XDC instruction does nothing on my flashcart, but stepping through the MAME debugger shows it executing XDC at 87Ch, 886h, 888h, 891h, 893h, 8a5h, etc. in Mad Genius.bin. Makes sense since the 3853 SMI has a 2^nd DC. It's a trivial fix, but I won't be able to test it for a while. Seeing as how I haven't encountered issues with other ROMs so far that's probably it. I wonder if any Videocarts rely on there only being one DC. Doubtful, but I guess we'll find out!

 

Ooh, sounds intriguing, haha. Quite the collection you've got there; I felt mad for owning three Channel Fs. Consider yourself signed up for the beta as well then! As for the box, I'll contact my local printer to see what prices would be like. If you could DM me any templates or dimensions that worked well for you that'd be great

 

Nice to hear the Arlasoft Collection is coming along, can't wait to get one

[+fdr4prez]

18 hours ago, 3DMAZE said:

I felt mad for owning three Channel Fs.

I own three Channel Fs, and I am mad too because none of them are working and they are in various states of disassembly and repair. 

[e5frog]

@3DMAZE

Is your Channel F glitching on any cart you try?

 

So regarding the .CHF file format. 

I disagree cartridge types should only include banking schemes, any type should be described, how would one add port-connected RAM as a CHIP packet?

The packets describe memory content of an address range. 

 

The type should be a description of the hardware used that the memory description doesn't cover. 

 

Adding a length parameter for the title seems logic. "The Arlasoft Collection" is 23 letters with no author included for example. It does look pretty nice in a hex editor to have the CHIP packets evenly spaced, perhaps the end of the header should be rounded up to an even 0x*F so a CHIP packet starts at 0x*0

I don't think there should be separate sections for author/track/album/shoe size/facebook status...  it can be included in the variable length title field if needed. 
Two bytes should be enough? Or should it be future proofed with four bytes? I guess it's better to have four bytes describing all lengths - in case someone comes up with anything fun to use it four - it would still work as a regular cart no matter what is put there. 

 

 

This takes us here:

First row is the magic key - header to check if it's the kind of file we want, CHANNEL F, the rest is "Don't Care", ANY filler characters to 0x0F. 

0010-0013 header length, endian type of your wish, padded to end at even 16 bytes $***F
0014-0015 .CHF file description version - our first is 0100 [v1.00]
0016-0017 Cartridge type, maximum 65535 different types. 
0: ROM
1: ROM + port RAM
2: ROM+RAM (With 3853)
3: SABA Videoplay 20 (as 2 but also a LED)
4: Multi-Cart (As 2 with selectable banking)
6: Upcoming cartridge types that can't be covered by the descriptions above
7:
8:
...
0018-001F for something possibly in the future
$0020 Start of title data - end is already set by header size 
Header has been padded to reach 0x*F - so the CHIP packets look nice in hex editor.

 

We agreed on the CHIP packets, right? 

 

  Offset: 0000-0003 - Signature "CHIP"
          0004-0007 - Total CHIP packet length
          0008-0009 - Chip type
                       0 - ROM
                       1 - RAM, no ROM data
                       2 - Flash ROM
                       3... etc etc etc whatever
                       4...
          000A-000B - Bank number for banked carts ($0000 - normal cartridge)
          000C-000D - This chip's start address (when available to CPU)
          000E-000F - The memory size of this chip part in bytes
          0010-xxxx - The actual data of the chip 

 

Seems easy enough, any objections?

 

We need to "sell this" to the emulator makers as well... 

I'll try and do my part, making odd carts that needs this.