Movie Cart

[larsvonhier]

Got my two cards, thanks @rbairos

Tested them on my JR (PAL with composite video output). Will also try on the FB 2.

[+rbairos]

3 hours ago, larsvonhier said:

Got my two cards, thanks @rbairos

Tested them on my JR (PAL with composite video output). Will also try on the FB 2.

Awesome.  I actually think it looks best on the FB2. 
That's where it all got developed and it always interlaces it nicely, unlike modern LCD TVs I find.  (For my 2009 LCD TV, I power off/on to get the interlacing right).
 

[+rbairos]

9 hours ago, Sikor said:

Finally, a few of my comments/suggestions.
- As you know, my cases are made in the style of Atari cases for 2600/7800, but over time some PCBs have changed slightly (the cases too)
- the SD card slot should be closer to the edge of the housing (the width of the Sikor Soft housing is identical to the width of Atari housings, so in my opinion the PCB needs to be slightly wider), but this is my opinion
- the width of the PCB at the mounting point could be reduced slightly (max 0.5mm)
- I'm not entirely sure whether I had to cut out the brackets, I don't remember if when designing I had a PCB from the 7800 cartridge that had cutouts for mounting in this place, or whether the board was based on these brackets.
To sum up - an excellent project, as soon as I find some time - I will make a cutout for the SD card and stick stickers

 

Hi Sikor.
Thanks so much for this very detailed analysis.

I'm open to changing the design of the PCB, as I need to make a bunch more, but I want to make sure it still fits in a standard Combat shell.
In my testing with the Sikor shell, I noticed a Combat PCB also had similar issues. ie, it kept slipping out of place with a little pressure, even closed.

(see attached picture for locations of A,B,C,D)

A) Top corners:
I think I could also shave these off without compatibility issues, or better yet, small angled cut to match those your posts.

B) Center post hole:
Mine is standard and just greater than 1/4" (actually 17/64") and I see yours is quite thin.
If yours was standard size it would stop the PCBs from sliding up and down altogether.
Another solution would be plastic tube stock with the exact inner and outer radius that could be glued over your post, thought that might be hard to find.

C) Tab width:
I agree, I could deepen the holes slightly, and still be compatible with Combat shells. (I think..)

D) SD Card closer to the edge:
Many people have asked for this, and I see the value, but again just need to make sure it still fits in a Combat shell.
Also, it still needs to be fully encased in shells that aren't supposed to have SD card access. Tough one.

E) Thickness:
They are currently 1.6mm, but the other options are 1.2 and 2.0.
Is that the thickness you mean? 1.2 seems dangerous.

Anyways great feedback.
Let's see if there's a good solution here.
Well wishes on your health and new job.
 

[Sikor]

15 hours ago, rbairos said:

B) Center post hole:
Mine is standard and just greater than 1/4" (actually 17/64") and I see yours is quite thin.
If yours was standard size it would stop the PCBs from sliding up and down altogether.
Another solution would be plastic tube stock with the exact inner and outer radius that could be glued over your post, thought that might be hard to find.

Problem is here, than, when i made form - i has 5 or 6 type of PCB's. This has size where any of them fit in. In combat enclosure there is hole for screw, if I remember.

15 hours ago, rbairos said:

D) SD Card closer to the edge:
Many people have asked for this, and I see the value, but again just need to make sure it still fits in a Combat shell.
Also, it still needs to be fully encased in shells that aren't supposed to have SD card access. Tough one.

Why there are needs to be fully encased in shells? I think, that better option is made some hole to replace SD cards with other ones, this is better option to replace card with new movies. I think, then the best option will be made it on the edge of shell.

16 hours ago, rbairos said:

E) Thickness:
They are currently 1.6mm, but the other options are 1.2 and 2.0.

1.6 or 2.0 is ok in my opinion.

Thanks.

[larsvonhier]

18 hours ago, rbairos said:

Awesome.  I actually think it looks best on the FB2. 
That's where it all got developed and it always interlaces it nicely, unlike modern LCD TVs I find.  (For my 2009 LCD TV, I power off/on to get the interlacing right).
 

Yeah, it really looks much nicer than on the JR (even with retro-fit composite out). I have given my LG 4K panel a shot (with both consoles) but interlacing does not really work there (also with other software and demos). On a cheap small panel TV it´s already quite good, but I'll also hook up the consoles to a real CRT-TV for best expected result.

 

I´d also like to humbly propose a little additional feature that would further increase the "show-off usefulness": Could the player cycle through all movie files one after another (in addition to the select-skip function)? 

[+rbairos]

3 hours ago, larsvonhier said:

Yeah, it really looks much nicer than on the JR (even with retro-fit composite out). I have given my LG 4K panel a shot (with both consoles) but interlacing does not really work there (also with other software and demos). On a cheap small panel TV it´s already quite good, but I'll also hook up the consoles to a real CRT-TV for best expected result.

Interesting info.
I wish the Atari 2600 had a native way of properly defining even/odd fields to fix that.  There's some discussoins on the forum somewhere, but nothing conclusive if I recall.

 

Quote

I´d also like to humbly propose a little additional feature that would further increase the "show-off usefulness": Could the player cycle through all movie files one after another (in addition to the select-skip function)? 

That's interesting.  It's been requested before.
wonder what the best way of doing that is.
4th menu entry (volume/brightness/timecode) might be overkill.
Maybe the difficulty switch could be used as repeat / stop button. Less discoverable though.
Changing the kernel that reads from the atari isn't changeable in my firmware update files unfortunately.
maybe a speciai 'config.txt' file on the SD card that specifies repeat or not.
Open to suggestions.

Btw, have you had any issues playing through multiple files? One tester recently saw some garbled video temporarily playing through the later files.

 

[+rbairos]

5 hours ago, Sikor said:

Problem is here, than, when i made form - i has 5 or 6 type of PCB's. This has size where any of them fit in. In combat enclosure there is hole for screw, if I remember.

Why there are needs to be fully encased in shells? I think, that better option is made some hole to replace SD cards with other ones, this is better option to replace card with new movies. I think, then the best option will be made it on the edge of shell.

1.6 or 2.0 is ok in my opinion.

Thanks.

So I think I found some 17/64 inch plastic spacers that might work well. 
If I did that and deepened tab holes (C) then everything might be solved.
Going to experiment with that.

The reason it shouldn't always have a hole slot for the SD card, is that aesthetically, its fun to have a collection where each cart is a dedicated movie with proper movie labels etc.
If there's a big hole in the side, it let's all the magic spill out!

 

[larsvonhier]

8 hours ago, rbairos said:

Interesting info.
I wish the Atari 2600 had a native way of properly defining even/odd fields to fix that.  There's some discussoins on the forum somewhere, but nothing conclusive if I recall.

 

That's interesting.  It's been requested before.
wonder what the best way of doing that is.
4th menu entry (volume/brightness/timecode) might be overkill.
Maybe the difficulty switch could be used as repeat / stop button. Less discoverable though.
Changing the kernel that reads from the atari isn't changeable in my firmware update files unfortunately.
maybe a speciai 'config.txt' file on the SD card that specifies repeat or not.
Open to suggestions.

Btw, have you had any issues playing through multiple files? One tester recently saw some garbled video temporarily playing through the later files.

 

Thanks for sharing your thoughts.

I´d be happy with any solution and think that difficulty switches could be some way of defining "repeat current" or "repeat all" files.

A config file on the card could also be some good way, also making further tweaks possible...

 

I had no corrupt file replay yet when skipping through movies with the select button. (Tested with 8-9 files on one card only so far).

[Bee]

 

I want to give a shout out to how nice this project is.  This my cart.

 

Thank you

 

 

 

[larsvonhier]

The results never stop to amaze me...

An excerpt from Dark Crystal (tv series). So beautiful when encoded and played right.

The Samsung screen does not interlace as a CRT would, but allows good control over picture settings as color and screen aspect (I set it to wide screen and this results in almost original pixel sizes in h/v scales).

 

 

[+karri]

Thanks for the cart!

 

My 7800 PAL always goes to the Asteroids game.

First I thought there was something wrong with the cart.

But then I tried the cart on my 7800 NTSC console and everything worked!

I also created a 3D print for the MovieCart. Enjoy.

MovieCart.stl

MovieCartTop.stl

 

 

[+rbairos]

3 hours ago, karri said:

Thanks for the cart!

 

My 7800 PAL always goes to the Asteroids game.

First I thought there was something wrong with the cart.

But then I tried the cart on my 7800 NTSC console and everything worked!

I also created a 3D print for the MovieCart. Enjoy.

Really interesting!
I just read on wiki:
"When a cartridge is inserted into the system, the BIOS generates a signature of the cartridge ROM and compares it to the one stored on the cartridge. If they match, the console operates in 7800 mode, granting the game access to MARIA and other features, otherwise the console operates as a 2600. This digital signature code is not present in PAL 7800s, which use various heuristics to detect 2600 cartridges, due to export restrictions."

I wonder if the 7800 PAL is thinking its a 7800 cart ??
If so I could possibly modify the cart to not show up as PAL somehow. Need more info.
Did you order the SDcard with the PAL or NTSC movie on it?
They're both available online if you want to swap it out:
https://github.com/lodefmode/moviecart/blob/main/docs/How_To_Update_Content.txt


Nice job on the STL, but from your pic, how does it stay in place and not fall out the front?
Is the SD card easily accessible?
I'm currently working on a revision that brings the SD card slightly over the left edge.



 

[+karri]

The signature is only checked on the 7800 NTSC. And the cart works in that console.

 

I have not tried to change the movie to  PAL yet.

 

My stl case was just a quick hack to ensure that I don't insert the cart in the wrong way. In theory I could try to wriggle the SD cart out through the slot but it is more convenient to open the screw and take out the cart when swapping the SD.

 

I printed the bottom in white and black. The top is stll in the printer. So it is not in the photo. A friend of mine is having a record release party tonight. So MovieCart has to wait for Sunday.

 

There is some Flag bits at FFF8 I think that were planned for region checks. I can look up this info tomorrow. Most likely when I wake up at noon...

[+karri]

From the Atari 7800 developers area:

 

The high nibble of $FFF8 must be $F.

The low bit of $FFF8 must be set. This was at some time intended for a

region setting, with the USA apparently being the low bit. So just set

$FFF8 to $FF (which should mean "all regions"), and forget about it.

The high nibble of $FFF9 must be $4-$F, and should not include the bank switch

memory range of a bank-switched cartridge. This should be set to $F for

fastest startup whenever possible.

The low nibble of $FFF9 must be 3 or 7. 3 will disable the k3wl Atari

rainbow startup graphics, but won't make the game start any faster. So use 7.

[+karri]

I had a pal movie on the cart but my 7800 PAL machine does not recognise the cart. It always starts the built in Space Invaders.

 

Changing the update.frm to the September 9th release made no difference. I also tried 20century_fox.mvc but it did not work either.

 

The cart works in my 7800 NTSC console. So there is nothing wrong with the cart.

 

PS. The bottom part is a single print. I just changed the filament to black when the print process came to the SD card slot. The idea was to have a black and white cart for an old movies Movie Cart.

[+rbairos]

2 hours ago, karri said:

I had a pal movie on the cart but my 7800 PAL machine does not recognise the cart. It always starts the built in Space Invaders.

Changing the update.frm to the September 9th release made no difference. I also tried 20century_fox.mvc but it did not work either.

The cart works in my 7800 NTSC console. So there is nothing wrong with the cart.

So the 7800 PAL is using a different algorithm to decide if its a 2600 cart from the wikipedia article.
I strongly suspect it's falsely recognizing the moviecart as one.
I'll think about it more.
 

[+karri]

I wonder if this info helps:

INPTCTRL REGISTER ($01)

The INPTCTRL register is responsible for switching and locking the 7800 into either 2600 or 7800 mode. It's a write-only register mapped to $0000-$001F, and controlled by external circuitry. INPTCTRL's address range overlaps TIA's address range. As a consequence, once this register is set you need to also set the lock bit (see below) before you can use the TIA.

There are 4 bits in the register:

INPTCTRL Bits

bit 3	bit 2	bit 1	bit 0
TIA-EN: 1 = enable TIA video pull-ups (video output is TIA instead of MARIA) and also disables 2 button joystick mode, 0 = disable TIA video pull-ups (video output is MARIA instead of TIA).	EXT: 0 = enable BIOS at $8000-$FFFF, 1 = disable BIOS / enable cartridge	MARIA Enable: 1 = enable MARIA (also enables system RAM), 0 = disable MARIA	Lock Mode: When set to 1 this bit locks the control register so that no more writes will affect it. The only way to clear the lock is to power cycle the console.

In addition to the functions controlled by the register bits, INPTCTRL also controls the HALT input to the 6502. When the 7800 is first powered up HALT is blocked from getting to the 6502, but after 2 writes to the control register (the data written doesn’t make a difference), the HALT input will be enabled.

 

Actually.. This does not help as it is probable written by the BIOS and not the cart.

[+karri]

I found a better source:

 

The BIOS compares FE00-FE7F with FE80-FF00 and if they are the same, it

assumes there no cartridge and jumps to internal game.

[+rbairos]

59 minutes ago, karri said:

I found a better source:

 

The BIOS compares FE00-FE7F with FE80-FF00 and if they are the same, it

assumes there no cartridge and jumps to internal game.

Huh. Interesting.
Okay that might be it. I'll have to dig.

EDIT. If so, I wonder if the Stella Emulator does this as well for PAL games.
That would make testing a whole bunch easier.

EDIT EDIT: Stella is just 2600 so probably not.

 

[+rbairos]

On 10/6/2024 at 2:06 PM, karri said:

I found a better source:

 

The BIOS compares FE00-FE7F with FE80-FF00 and if they are the same, it

assumes there no cartridge and jumps to internal game.

I assume you mean:   FE00-FE7F with FE80-FEFF

So looking at my kernel:
It's 512 bytes long.
The last 256 bytes (FF00-FFFF)  is the line drawing kernel.
The first 256 bytes (FE00-FEFF) are setup to be capture writes from the Atari 6507 to the bus.
I do this to capture joystick and switch values.
Example:

ldx SWCHA
sta   $FE00,x     ;'a'  is unused here

Then the 6507 sets the address lines to FE+X so I capture the state of the lower 8 address lines to get the value of SWCHA

So the 7800 PAL is going to incorrectly sample this range FE-- and get the same value.

That means, besides MovieCart, A 4K 2600 Cart with part of that section unused / set to constant will fail as well?
Might be good to confirm with a 1K cart sitting in a 4K ROM with FE-- set to constant.

Side note, do all 7800s have a built-in game?? I had no idea.
I acquired a 7800 NTSC for this project, how would I enter that mode?

If we confirm this, I think I can make a new type of patch.
Unlike the previous patches, this one won't be factory resettable though. I can test thoroughly.

Thanks.





 

[+-^CrossBow^-]

4 minutes ago, rbairos said:

I assume you mean:   FE00-FE7F with FE80-FEFF

So looking at my kernel:
It's 512 bytes long.
The last 256 bytes (FF00-FFFF)  is the line drawing kernel.
The first 256 bytes (FE00-FEFF) are setup to be capture writes from the Atari 6507 to the bus.
I do this to capture joystick and switch values.
Example:

ldx SWCHA
sta   $FE00,x     ;'a'  is unused here

Then the 6507 sets the address lines to FE+X so I capture the state of the lower 8 address lines to get the value of SWCHA

So the 7800 PAL is going to incorrectly sample this range FE-- and get the same value.

That means, besides MovieCart, A 4K 2600 Cart with part of that section unused / set to constant will fail as well?
Might be good to confirm with a 1K cart sitting in a 4K ROM with FE-- set to constant.

Side note, do all 7800s have a built-in game?? I had no idea.
I acquired a 7800 NTSC for this project, how would I enter that mode?

If we confirm this, I think I can make a new type of patch.
Unlike the previous patches, this one won't be factory resettable though. I can test thoroughly.

Thanks.





 

By default the NTSC consoles do NOT have an included game. That was in the PAL regions. Since then over the years, there have been modified BIOS for folks to install that do come with an included game. Two of my 7800s for instance have @PacManPlus and @RevEng's KiloParsec BIOS installed and those include the built in game Kiloparsec that Bob coded along with a few other tweaks to the BIOS code.

 

That said, both of those consoles are able to play the Movie cart just fine with both the 7800 corrected firmware and the newer movie select option firmware.

 

 

[RevEng]

On 10/6/2024 at 2:06 PM, karri said:

I found a better source:

 

The BIOS compares FE00-FE7F with FE80-FF00 and if they are the same, it

assumes there no cartridge and jumps to internal game.

I know the PAL bios comments say that, but it's not quite what it's doing. It's comparing FE00-FE7F to itself using two different base addresses, and indexes set to compensate. If the compared values don't match, then it jumps to the internal game.

[+rbairos]

13 hours ago, RevEng said:

I know the PAL bios comments say that, but it's not quite what it's doing. It's comparing FE00-FE7F to itself using two different base addresses, and indexes set to compensate. If the compared values don't match, then it jumps to the internal game.

What's the reasoning behind that? I don't quite follow.
What about 2600 carts that use that range with bank switching?

In MovieCart, FE-- always disconnects the PCB (hi-Z) from the DATA bus in that range, so I suppose the 6507 is reading random values.
Fixable, but annoying since the current solution is using a configurable logic circuit to avoid software overhead in that case.
 

[+karri]

As there is an easy solution to get a better boot ROM so just declare that it is not compatible with the PAL 7800  BIOS.

 

One more reason to update the BIOS rom.

[RevEng]

5 hours ago, rbairos said:

What's the reasoning behind that? I don't quite follow.
What about 2600 carts that use that range with bank switching?

It's basically a "cart isn't inserted" check. Due to bus capacitance causing a bit of hang-time on the last driven data bus value (when there's nothing driving the bus anymore) a naive check for no cart rom (e.g. look for all FF, look for all 0, check the same location many times, etc) often fails to actually catch a no cart rom condition. That last-driven value is usually the last byte of the opcode's operand. By using a different base address but reaching the same final address with different indexes, gcc forced the last-driven value to be different.

 

I'm not aware of any 2600 bank schemes that respond to FE00-FE7F. Are there any? If there are, it's a bit hard to say. Essentially the question of whether this scheme would pass this check or not can be reduced to "is the value returned from reading the same hotspot location twice consistent?" That's probably going to depend on the bankswitch hardware, rom, and console.