JetSetIlly
-
Posts
763 -
Joined
-
Last visited
Content Type
Profiles
Forums
Blogs
Gallery
Events
Store
Posts posted by JetSetIlly
-
-
5 minutes ago, Al_Nafuur said:
I just found on my harddisk a collect3 demo which I modified half a year ago.
it worked in gopher2600:
here is the code and the binary:
Collect3.zip 54.84 kB · 2 downloads
Github project. The second commit shows the changes I made to target PlusCart.
-
1
-
-
2 minutes ago, Thomas Jentzsch said:
Do you have some test ROMs?
No.
-
10 hours ago, Thomas Jentzsch said:
Yes, patching DPC+ is possible. But Andrew was asking for CDFJ. Any success with these?
Not a problem for emulators, all the pieces are there, so it should work using the same ROM compilation method as for DPC+ ROMs.
For the PlusCart itself, there needs to be a reimplement of the CDFJ functions that are present in the Harmony driver.
-
59 minutes ago, Thomas Jentzsch said:
Is it really that simple? That you only change the memory map and a program written for Harmony will run on PlusCart and vice versa? Aren't there any special functions used which differ between hardware?
Same for emulation. Just change the address offsets and then you can emulate programs written for STM32F?I expect there'll be other complications but the first step was to change the memory map for the new processor. I left it with @Al_Nafuur but I got the impression that he had compiled Harmony programs for the PlusCart's CPU and managed to get them running.
This is the memory map definitions for Gopher2600. As you can see, I've not identified the registers for the Timer or the MAM (I'm not even sure if there is a MAM in the STM32F). So as long as you don't need the timer then I suppose this is okay.
-
1
-
-
29 minutes ago, Al_Nafuur said:
this ROM can be tested on gopher2600 when the "hardware.arm7.model" property in the preferences file (https://github.com/JetSetIlly/Gopher2600#configuration-directory) has been switched from:
hardware.arm7.model :: LPC2000
to:
hardware.arm7.model :: STM32F407VGT6
To be clear, this only changes the memory map. Cycle counting will be different - it'll be similar but there's bound to be differences.
-
1
-
-
This version of the bot is working only with visual and audio cues. There is no direct access of the emulation's memory.
The plan is to extend this framework to other games but obviously, most other games are more complex so that will be quite a challenge. Combat would be a good second project I think.
-
2
-
-
A longer video of Video Chess playing Stockfish.
The bot is moving a little bit quicker now. I don't think I can't get it going any quicker though because of how Video Chess works. I certainly don't think I can just poke values into memory but I could be wrong on that.
-
8 hours ago, Andrew Davie said:
Ha... very neat indeed! I had a dream of getting my chess engine to play online engines via PlusCart, but that never eventuated.
That sounds achievable. You should finish that project off.
-
I was watching game 4 of the Chess World Championship this afternoon and stared thinking about computer chess. Specifically, whether I could get Video Chess to play against an external chess engine. Here's the first attempt. Video Chess is playing black.
It should work against any standard chess engine but in this instance I'm using Stockfish.
-
1
-
-
1 hour ago, Andrew Davie said:
Because it seems Stella (by default, I guess - I'm probably running an old less-capable version - 6.5) does not cycle count ARM code in normal mode, I am constantly switching between code that "looks good in stella" and code that "looks good in Gopher (and presumably hardware)". It's to do with where I call ARM code -- in default config, Stella runs all this at super-speed, so the rotation speed is insane. I will include a binary (superfast) to show this. Compare running the same binary on Gopher and Stella to see the difference. I think Stella might be better with cycle counting on by default so this sort of thing doesn't happen. Of course I could be misunderstanding what's going on... but the differences between running "superfast" in the two is quite telling.
I've not dug into it too much but a quick look at what's happening to the memory in the ARM, it looks like there's a value in RAM that's not being updated when cycle counting is off. It looks to be a value that's copied to address 0x82 of the VCS RAM (or maybe the other way around). That might be a clue as to what is happening.
-
5 hours ago, Andrew Davie said:
This version has improved timing, and should run OK on Gopher, too.
Excellent. In the latest binary, you're not using much ARM time at all compared to previous versions, so you have lots of room for more processing.
Incidentally, all versions work OK on Gopher2600 but cycle counting is on by default, so for earlier versions of your binary you need to turn it off, or the scanline count is unstable. In the latest version of Stella, it is the other way around - cycle counting is off by default and on in developer mode.
-
10 hours ago, Gip-Gip said:
Hey all! Long time no see!
I'm doing atari repairs on the side of my current job/future college and I want a stress test cart for making sure they all work as intended
So far I have some ram test code laid out, along with some TIA test code in mind, and I'm wondering what ideas you guys have for testing the 2600 to make sure it's in 100% working order
I'll have the source code up when I have it in a good state, per usual, and I'll try my best to keep it semi well-documented. Granted, it's hard to make good looking assembler, but I will at least try my hardest to make it half readable
Plus, it's been a solid year or two since I've worked with assembler, so forgive me if it isn't the best code you've ever seen
Currently my list of tests include:
- RAM test, write both $FF and $00 to each byte in ram
- TIA test, set background color to each possible tia color in a rainbow fashion
- Sound test, cycle through sounds per frame
Please give me other stress ideas, what other common failure points there are, etc. etc.
There's the Atari Diagnostic Test Cartridge which came with a Field Service Manual. That would be good for you to get your hands on. Example page below.
Just six basic tests so it would be nice to have something more comprehensive I think.
-
2 minutes ago, Tempest said:
Wow that dual window emulator with the third showing the differences (is that part of the emulator?)
It is.
2 minutes ago, Tempest said:would really come in handy for seeing differences between some of these prototypes
So the 'seed' for the position and number of craters and planets and whatnot is different because the code is different between the two protos isn't the same, but the code for these routines is actually the same? I know that sounds contradictory, but you get what I'm saying right?
I don't think we tell from this if the routines are the same or not.
All we can say is that the starting seed is different - there's no randomisation from any other source and the user input is the same. Why the starting seed is different I'm not sure. My guess is that it's a magic number in the binary.
Has anyone ever done a disassembly of Solaris? It would be interesting to know what randomisation method it uses. We might then be able to force the use of the same seed to test whether the routines are the same.
2 minutes ago, Tempest said:One thing I see from your clip there is that one version takes longer to bring up the map screen after blasting off.
That might be because that particular sequence takes longer. Sometimes, the map screen comes up at the same time.
One thing I did notice is that shade of blue in the compass is sometimes different on the map screen. This isn't a difference in the binaries I don't think because it doesn't always happen.
2 minutes ago, Tempest said:would really come in handy for seeing differences between some of these prototypes
Yes. Once I've nailed down the synchronisation so that it's perfect, it could be a useful tool.
What it would be useful for is testing for differences between machines. So two emulations using the same ROM but the emulation is using a different TIA revision. That would quickly tell us whether a ROM plays or looks different on different versions of the 2600.
-
4
-
-
14 hours ago, Tempest said:
Yes I think it would. Do most games play the same or do most randomize things?
There is no randomisation in the emulation for these tests. Any random elements can only come from user input. The effects of which I've mostly ironed out by running the two emulations in parallel. This should mean that any differences we see come only from the differences in the binary itself.
14 hours ago, Tempest said:So what did you see in Solaris?
The first difference I can see is that the pre-release must be started with the panel's start switch. The release version that I have can be started with the joystick's fire button.
Visual differences in the video below. As I say there is no randomisation and the video is shown from startup, so the differences in the planets/craters is caused by the initial state of the binary itself. The only user input is pressing of the start switch and then the fire button to get the ship moving.
Trivial differences really. All this tells us I think, is that the starting state of the binaries are slightly different.
Synchronisation of the emulations is tricky. The previous video was being synchronised by frame (so the visual differences are matched frame by frame) which is fine, but it's possible for user input to be given on or near a frame boundary. This means that it is possible for one emulation to receive the input on one frame and for the other emulation to receive it on the next frame.
The previous Pitfall video I believe that's what happened in the second half of the video when we see the screen having been scrolled by slightly different amounts. It makes more sense that this was caused by a slight difference in user input than any differences in the binary. It should be possible to synchronise input exactly but I haven't done that yet.
-
2 minutes ago, Tempest said:
I do something similar running two emulator windows side by side, but I haven't figured out to have input go to both at the same time. How are you doing that?
It's my own emulator called Gopher2600. I added the comparison window this evening so this tooling is brand new. If you think it would be useful I can polish it up and make it more usable.
I had a quick look at the Solaris ROM and it was quite successful at showing the differences with that too.
(I just had another watch of the YouTube video and I noticed that the first glitch as you fall in the water might not be visible unless you're running the video at 720 60fps)
-
I thought this was an interesting puzzle so I thought about how we could perhaps make an automatic tool to illustrate where a game plays differently.
I've hacked up my emulator so that it runs two emulations side by side, with the two different ROMs. Both emulations receive the same user input.
The video below shows what I found. The large screen is the known good dump of the Pitfall 2 ROM, while the smaller window has the "beta" ROM in the top part and a screen showing the visual differences between the two ROM in the bottom part.
The first minute or so there are no differences apart from the visual glitch that has already been found and a small difference in the water snake (probably been run a frame behind). This shows that the tool basically works as intended I think.
After I die and go back to the beginning, I manage to trigger some differences, with quite a dramatic difference when I fall into the water for a second time. It looks to me like one or other of the ROMs hasn't quite scrolled by the same amount.
What's interesting about this is that the different persists right up to when I pick up the gold bar. At which point the two games come back into alignment.
-
3
-
-
Version 0.15.
Major change this version is the ability to switch between debugger and play mode with the key below the escape key - tilde key on US keyboard (the same default key as in Stella).
There is also a ROM requester that will show on startup meaning that the emulator can be now be launched from the desktop. The requester window will show a thumbnail for all supported ROMs.
Performance is also improved I would say and there is a new interference effect in the CRT emulation.
Full changelog on the release page: https://github.com/JetSetIlly/Gopher2600/releases/tag/v0.15.0
Some features are better shown rather than described so I made a short video illustrating some of the most interesting ones introduced this version. (Best viewed in HD 60fps)
I've tried adding an icon to the Windows binary but it's not that successful yet. It definitely needs some work. It's based on a fun logo I made this morning. The logo works but it's too complex for an icon.
As ever, feedback is welcome.
-
6
-
-
8 minutes ago, Andrew Davie said:
Here's a binary -- all you can do is watch. Or, hold RESET to restart.
This almost certainly only runs on stella at this stage...
The demo looks very effective. (It also runs on Gopher2600 if you turn cycle counting/enforcement off)
-
Another demo video of the tracker window. This time with piano keys.
I'm quite pleased I can do this sort of stuff in regular playmode without any performance drop. It opens up other possibilities too I think.
-
7
-
-
35 minutes ago, rbairos said:
Hey Everyone.
I'll be doing a live broadcast through work, covering some of my art projects over the years, including covering the MovieCart encoding process in more detail if anyone's interested:
Apologies in advance if I flub some of the 2600 specs:
Friday November 5th 4:00pm EST
https://derivative.ca/event/touchdesigner-insession-160/65407
Tuning in for the Donkey Kong zoetropes. That sounds like fun.
-
Video showing new audio engine. This is a straight reimplementation of @Crispy research and is the same as 6502.ts and Stella. Sounds pretty good I think.
The video also shows a new Audio Tracker window. Early stages of development yet but it's helped me track down a bug so it could be useful for regular development work too.
Thanks to @DirtyHairy for pointing me in the right direction for the engine implementation.
-
4
-
-
19 hours ago, DirtyHairy said:
@CrispyTo my knowledge, the only missing detail is that volume changes are only applied when a new sample is generated (which is twice per scanline), while the change takes effect immediately on hardware.
Are there any example ROMs where this is particularly noticeable?
-
15 hours ago, DirtyHairy said:
Have a look at the audio implementation in Stella or 6502.ts, they are based on a C simulation of the noise generator circuit kindly provided by @Crispy, and they are much more correct. To my knowledge, the only missing detail is that volume changes are only applied when a new sample is generated (which is twice per scanline), while the change takes effect immediately on hardware.
Thanks. I've made some progress with that.
Question: Why is the tone generation divided into two phases? Phase 0 at the first 114 clock and Phase 1 at the 228 clock. The results are similar (to my ear) if you run both functions every 114 clocks and create an output sample then. Is this a reflection of the hardware somehow?It's okay. I see what it's doing now.
-
I'm hoping someone can help me with the Audio implementation in Gopher2600. It's mostly okay (correct) but there are a couple of things which don't work correctly.
I've implemented the volume mixing as described in the document "TIA Sounding Off in the Digital Domain" by @Crispy and to my ears that correctly implements the MsPacMan music distortion (I've attached a WAV file) mspacman.wav
On its own however, this doesn't fix the the ET spaceship effect et.wav or the phaser06.bin demo ROM phaser06.wav (WAV files of current Gopher2600 version)
My code is based on Ron Fries original TIASound.c file and the volume mixing taken from the "Digitial Domain document".
What am I missing or misunderstanding?
Like us on Facebook
Follow us on Twitter
AtariAge on Instagram
Watch us on YouTube
Chat on Discord
CDFJ support?
in Discussion
Posted
If you've coded with the assumption that Flash Origin is at 0x00000000 then you're going to need to change more than the header files. The diff file below shows how I needed to add the "ROM" address to "offset" values in a few places.
https://github.com/JetSetIlly/plusromtest_cdfj/commit/33d400d2ceb9ea8be7dc3c0178b812236f224fc9#diff-2978fe1c2c45b4eca89dc476376ddc7193bc4e5e7fff0c7d1c465f057b35a5e6