JetSetIlly
-
Posts
763 -
Joined
-
Last visited
Content Type
Profiles
Forums
Blogs
Gallery
Events
Store
Posts posted by JetSetIlly
-
-
Based on what I'm reading from some of the people I respect most in the community (Andrew, Alex, Thomas, et al) and the fact that what is being said chimes with my own instincts, I feel there is now a need for a third-party forum for collective discussion of the 2600 (and 7800 etc.). I don't know what it would look like but a mailing list is probably a good starting point.
(I realise that's highly ironic but that's all I have this morning)
-
3
-
-
7 minutes ago, Thomas Jentzsch said:
I know. I meant that I have no clue, if it will ever become relevant and how to dump it.
Oh I see. Sorry 🙂
-
9 hours ago, Thomas Jentzsch said:
Here is some basic overview I just created:
MVC is moviecart
-
16 hours ago, alex_79 said:
The 1978 Atari arcade "Tournament Table" (a cocktail table style cabinet featuring some pong variations) is based on the VCS hardware and it too has differences in memory map:
The TIA is active when A12,A11,A10 and A7 are "0". (two more bits decoded compared to the VCS)
The RIOT is active when A12 and A11 are "0" and A7 is "1", with A9 selecting RAM (0) or I/O-TIMER (1). (1 more bit decoded compared to the VCS)
A second RIOT is installed, active when A12 and A11 are "0" and A10 is "1", with A8 selecting between RAM (0) or I/O-Timer (1).
The area from $0800 to $1fff is used by 6K of non bank-switched ROM containing the game code.So that machine has 256 bytes of ram, double the I/O and timers and 6 Kb of ROM in the same 8k address space of the 2600.
(For anyone who will care to check the resulting memory map, yes, just like with the "POP" above, there are some memory areas that will cause bus contention between 2 chips, in this case the 2 RIOTs. Again, it is left to the software to avoid accessing those addresses...)
Amazing! Are the game ROMs for the Tournament Table available anywhere?
-
@ZackAttack has put together an intriguing ROM using the new ELF/StrongARM "bankswitching" format. This particular ROM, Wushu Masters, has given me a real headache and for the longest time it looked like this:
Obviously wrong but it wasn't at all obvious what the problem was. All the ARM instructions it uses are used by other ROMs which work just fine.
This morning Zack pointed out that I wasn't executing the .init sections in the ELF file. I was loading them but not executing them. As the name suggests, these sections point to initialisation functions that must be run before the main() function.
A quick change to the emulator and the problem immediately resolved itself:
Selectable characters, scrolling background and great colours. I hope @ZackAttack finishes this. It looks to be tremendous fun 🙂
-
7
-
-
4 minutes ago, MarcoJ said:
Very happy.
Is that the version of the RPG I have here Marco?
-
3 hours ago, Omegamatrix said:
Updated routines for delay using X or Y (DELAY_X and DELAY_Y).
Why have you chosen to avoid using illegal opcodes?
-
<removed>
-
1 hour ago, Thomas Jentzsch said:
BTW: Did I miss the discussion about how the StrongARM library etc.? Or has that not been discussed at AtariAge before?
StrongARM has been around for a while but @ZackAttack will know for sure. I think it came about as a consequence of the bus stuffing experiments.
-
8 minutes ago, Thomas Jentzsch said:
Are you "racing" the 6507 with the ARM now?
That's a good way of thinking about it.
10 minutes ago, Thomas Jentzsch said:So that there is no fixed 6507 (kernel9 code, just code generated on-the-fly by the ARM?
That's right. In a pure StrongARM ROM there is no DASM stage, it's all C (although it doesn't have to be C of course). The 6507 code could be different for every frame.
-
3 minutes ago, Thomas Jentzsch said:
Thanks for the input. Yes, emulation seems tricky, especially now that you are running at 216 MHz. Probably one could emulate the 6507 on one CPU and the ARM on another one (per thread), but that seems to be it, right?
I'm not sure there's any benefit to that because you need to keep the CPUs in synchronisation. Any advantage of parallel computation is lost because the synchronisation points are so frequent. That's my feeling anyway. It would be worth implementing and measuring.
11 minutes ago, Thomas Jentzsch said:What exactly is the StrongARM library? I understand that it is compiled for the target CPUs, but what's its content? And how much is it used?
The StrongARM library contains functions that facilitate the insertion of 6507 instructions into the data stream. For example, the StrongARM function vcsJmp3() inserts a JMP instruction.
The implementation for Gopher2600 is here, to give you an idea of what's involved: https://github.com/JetSetIlly/Gopher2600/blob/master/hardware/memory/cartridge/elf/strongarm.go (Note that I've tied StrongARM to the ELF loader but it could theoretically be used with the ACE loader too)
-
1
-
-
3 hours ago, ZackAttack said:
How about compiling the game and emulator to webassembly and running it in web browsers? It might just be crazy enough to work.
Funnily enough, that's something I've looked at and kept on the back burner for a couple of years.
I've built the emulator so that the 2600 engine can be compiled into other things, including other GUI systems and I have a version that can be compiled to WASM. It's only a proof of concept so no debugger etc. but it runs, albeit too slowly to be of any use. I don't know what to do about it to be honest.
-
7 minutes ago, Thomas Jentzsch said:
But I wonder why this is even required to that extend. Developers know that having enough CPU power can lead to lazy programming. Quite the opposite of what you would expect from a 2600 game.
This is a philosophical question really. It's something I've thought about and I do have my own answer but I don't have the time right now to write it out 🙂
10 minutes ago, Thomas Jentzsch said:Yes and no. If the emulators cannot handle these ROMs for the players, then many people will be excluded from playing them.
Marco and Zack are making these games regardless of whether emulation is possible. I view my role as making their life a little easier by providing tooling to make the development cycle faster and to provide insights into what is happening in their C programs.
But I definitely take your point about being able to play the games and I'm thinking hard about how to improve the situation.
-
1 minute ago, Thomas Jentzsch said:
Why is that so? Does emulating the CPU require that many resources? Or is the code just not optimized yet? Or both?
Great question. The main difference is that in Marco's ROMs and Zack's StrongARM ROMs, the ARM is being emulated for the entire screen, and not just just during VBLANK and Overscan like you would typically see in CDFJ ROMs.
I don't think there's much more I can do in the way of optimisation. In the case of the StrongARM ROMs though, there are library calls that have been implemented natively and those ROMs run much faster.
The performance drop is similar to what would happen if, instead of implementing CDFJ natively, we executed the instructions in the Harmony ROM under emulation and relied on the Harmony implementation. Although the drop wouldn't be as dramatic because there are fewer instructions per colour clock in the case of the Harmony ARM.
I'm not too worried about the performance though. I think the real utility for this is ROM development. Faster would be nice but I have a couple of ideas for how to improve the development experience in lieu of that.
-
I've been working hard, with help from @MarcoJ, to knock the bugs out of the ARMv7-M emulation in Gopher2600. This type of ARM is found in the PlusCart and UnoCart and @MarcoJ and @ZackAttack are making good use of it. The FPU emulation has proven especially challenging.
There's still a lot of work to be done but today I reached a significant milestone by gettng Marco's XWing / TIE Fighter 3D model demo working. Short video captured from the emulator below:
To be clear this is not real time. The emulation is currently running at about 5fps on my machine. By way of comparison, the ARM in the Harmony is emulated at well over a 100fps.
In addition to the 3D models, Marco's demo features music which relies on the FPU. This is also working under emulation but there are tuning issues so I won't post the results here just yet. I think the tuning issues are due to incorrect timing between the VCS and the ARM (the timer2 peripheral in the ARM being updated incorrectly/inconsistently) but I'm not entirely sure about this. More research and experimentation required.
As part of the process of bug finding process, I've improved the breakpoint system and the reliability/accuracy of local variable inspection. I've also added the ability to step by ARM instruction for super-detailed understanding of what is happening in the ARM registers.
I'll polish up what I have and hopefully have a new release in a couple of weeks. For anyone who is interested all code has been pushed to Github.
Steve
-
6
-
1
-
-
8 hours ago, Aleksi Eeben said:
I briefly peeked into Stella 7 code and noticed there's some constants that are approximate, such as the "about 30 kHz" clock being 31440/31200 Hz (NTSC/PAL). When I calculated those for the Star Bars frequency tables from CPU clock speed and actual frame rates I got 31399.5175/31113.1053 Hz. But those probably cancel out when Stella targets to 60.00/50.00 FPS instead of 59,92/49,86 FPS, and in any case the difference is minimal: 1 skipped frame every 16 seconds on NTSC or 8 seconds on PAL. Maybe that could be enough to cause a different note of the scale to be problematic on Stella than on the HW? I can't fully figure it out in my head, when everything is affecting everything, so HW/Stella wolf tests is the way
I did even experiment with changing myDivCounter to a downwards counter that resets at zero to AUDF value (removing "overflows" caused by rapid AUDF changes), but then we lose the E.T. landing sound and phaser06 test doesn't sound right (if I got it right in the first place).
Have you read the research done by @Crispy on this subject? The PDF is worth reading in detail if you've not done so already.
-
1 minute ago, xeex said:
Here is some more footage of the game without the screen transition glitches. Is this running from a cartridge on a 2600, or in Stella using a controller with a USB adapter? I don't know. The mystery deepens. I hope @ZeroPage Homebrew can address these issues during the interview today.
The TV it's been played on might not be sensitive to whatever is causing the issue for the video capture
-
6
-
-
8 hours ago, ZeroPage Homebrew said:
John Mikula says he programmed it in assembly in this video (@ 11m7s)
Thanks for the video link. It was interesting to hear him put the game into context.
-
1
-
-
16 hours ago, Dreammary said:
Anyone else have issues loading the multiload survival island rom onto their UNO cart? I can get every other game to work fine but Survival Island fails when you get to the second level and if you enter the code it gave on reload it still won’t work. I tried the file in an emulator and it worked fine but it won’t work right on my Atari 2600 Jr.
I think this is just because RAM is not initialised correctly. If you play through the first level then there are values in RAM which define the "duration" and "life" you were left with at the end of part 1. In other words, the game loop is testing for your end-of-life and ending immediately.
Maybe there could be a special initialisation in the Uno/PlusCart firmware for multi-load tapes. This way the RAM can be initialised "correctly"
For completeness the RAM addresses are:
$f4 - last two digits of the life value
$f5 - last two digits of the duration value
$f6 - first two digits of the duration value
$f7 - first two digits of the life value
I've not studied the other addresses but I'm guessing some of them are seed values for placement of the treasure and traps.
-
1
-
1
-
-
Some interesting stuff in there. I think there's scope for further research.
I'd like to see the WT internal documentation mentioned in the paper. There's an image of the cover but no links to the actual document. Does anyone know if this exists?
I'd also like to see more information about HRCALC and CHRST. Both are in Carol Shaw's papers but I can't seem to find scans of those. Has anyone seen these original routines or have any more details about them?
-
This entire conversation is bizarre. I'm sorry I got involved in it.
-
4
-
-
Thanks. I see what's happening now.
-
1
-
-
25 minutes ago, MrTrust said:
Like everything else that's been brought up, it's not a question of whether it's reasonable or not.
As a buyer, I'm just not going to agree to these terms, because I don't want to deal with the headache. If I end up in a situation where I need or want to sell off my video game stuff, I just want to take it to the local resale or throw it up on eBay, get the cash, and be done with it. I will not spend more than maybe $20 on a game I do not outright own, and even then, it's got to be something I want quite a bit and am confident I will get my $20 in a hurry.
But you do own it outright. You can sell it to whoever you like for whatever money you want. You could even destroy it if you wanted, because it's your property.
The only difference is that if it's an artwork (which is quite a high threshold to attain) and it's sold for over a $1000 (or euros, or whatever) and the sale was "public" then you may owe 5% resale royalty to the artist if they want to pursue it.
31 minutes ago, MrTrust said:Somebody's got to collect and disburse those royalties, and they're going to get their rake of it
In the existing systems we're discussing here, there is no rake.
-
Nice idea!
I don't understand how sub-expressions work though. For example, what is the correct form if I want to use the result of "+ 1 2" to multiply by 3?
Like us on Facebook
Follow us on Twitter
AtariAge on Instagram
Watch us on YouTube
Chat on Discord
AtariAge + Atari Q&A
in Atari General
Posted
It's worth emphasising that an important part of GNU GPL compliance is the right (or the ability) to install modified copies of the compiled source on the hardware. I assume the 2600+ allows this but have not read anything specific (I could well have missed that detail)