JetSetIlly
-
Posts
763 -
Joined
-
Last visited
Content Type
Profiles
Forums
Blogs
Gallery
Events
Store
Posts posted by JetSetIlly
-
-
9 minutes ago, Karl G said:
Wow ... that is ambitious for sure. Count me as someone who would be interested to see this as well. My reason would be the ability to use a much better/friendlier debugger than the MAME debugger when developing 7800 games.
It is ambitious but it's worth trying. I plan to start looking at it this summer, time permitting.
-
4
-
-
Just now, alex_79 said:
You can find some info in this thread. Note that AFAIK there aren't recordings of the original tapes available, which would be nice to have for preservation purposes.
The original tapes are in stereo, with music on one channel and data on the other one, which was converted to digital signals by the KidVid tape deck and then sent to the 2600 controller port.
The data track is not part of the available samples because, when support was added to Z26, it was reversed engineered and hard-coded into the emulator.
Thanks. That's a great starting point.
It would be nice to have the stereo tape. I'd be interested in emulation without any hard-coding of information.
Just now, alex_79 said:Do you mean the different initial state (because of the 7800 bios running before starting a game) and "Pause" switch instead of the "TV-Type" toggle, or do you plan to add full 7800 emulation?
@ZackAttack wants full 7800 emulation. It'll be useful to have because it means we can then use emulation to help develop ELF/StrongARM games for the 7800 as well as the 2600. I might need to make some architectural changes to the code first, but it should hold up nicely.
-
1
-
-
Just now, Thomas Jentzsch said:
It is not so much the format (which is complicated enough, you can check the Stella code for KidVid), but having to listen to the tapes over and over again while developing.
LOL
-
Just now, Thomas Jentzsch said:
You will regret this! Trust me.
Haha. I know literally nothing about the format so maybe I have been a bit hasty 😆
-
5 hours ago, gambler172 said:
Berenstain Bears needs also the mp3 files.
You can find them at Atarimania.
Oh I see. 'Berenstain Bears' and 'Smurf to the Rescue' are KidVid ROMs.
I don't know anything about KidVid but I would be interested in getting them working correctly. Time is tight for me at the moment but I'll put it on the TODO list.
The items on the list I have currently (in no particular order):
1. Joy2B+ @r_chase
2. Finish (and debug) Thumb2 emulation and get ACE working correctly @MarcoJ
4. 7800 emulation @ZackAttack
5. KidVid @gambler172
There are other items of course but these are the ones people have asked for. Hopefully I've not missed anything.
-
2
-
-
2 hours ago, gambler172 said:
Well...saw this emulator for the first time. Can it play Berenstain Bears? And Smurf Saves the Day?
Well, the ROMs load but they don't seem to do much.
2 hours ago, gambler172 said:Is Dragons Lair possible?
Cause someone told, he ported it for the Moviecart.
The emulator can run Moviecart files.
-
1
-
-
Working with @Gemintronic to get the macro system working for his use case.
It turns out that a POKE command is useful. There's always been a POKE command in the terminal language but it's useful to have in the macro language too.
To give an example, the following script automates the capturing of screenshots for every screen in Pitfall
gopher2600macro 1.0 -- start game by moving joystick right RIGHT CENTER -- loop through all 256 screens DO 256 n -- position player at right of screen POKE $e1 $94 -- walk right to next screen RIGHT WAIT 10 CENTER -- screenshot SCREENSHOT %n LOOP QUIT
There are other possible ways of achieving this for Pitfall, I'm sure.
My goal is to make the system flexible enough to enable the writing of automatic tests for people to use during ROM development.
Code is in the macro_system branch in the github repository.
-
4
-
-
Very quick hack but it works quite well I think.
Code is in a temporary "macro_system" branch. I'll merge into master if testing goes well.
All the interesting code is a single file.
The macro file used in the video is as follows:
gopher2600macro 1.0 DO 6 WAIT 120 SCREENSHOT SELECT WAIT 2 SELECT RELEASE LOOP QUIT
Wait values are number of frames. Loops can be nested.
It's probably good enough for your purposes now but I can add more instruction if needed. Do you need me to compile a binary for you or can handle that yourself?
-
3
-
-
4 hours ago, Gemintronic said:
Any chance input macro support is bring considered? Right now I'm testing procedural dungeon creation and I have to manually take 128 screenshots. If I could toggle turbo mode, move with the joystick and trigger a screenshot with a script/macro I'd be in heaven
Nice idea!
One thing I have in place is a way of recording input and being able to play it back, testing the integrity of the emulation as it proceeds. I developed it so I could experiment with the emulation and to make sure that I didn't break any previously working ROMs. It's not quite suited to your needs but I'm sure I can adapt the system so that it will.
I'll play around with it this weekend and see what I can do.
I'll probably come back to you with questions about what you need.
-
1
-
1
-
-
1 minute ago, Al_Nafuur said:
The real danger is when the AI doesn't needs politicians to make decisions..
That's a different real danger and it's a scenario that isn't possible with this version of GPT. Human beings making decisions and using a false authority to hoodwink the public is a danger that is relevant today.
-
9 hours ago, Andrew Davie said:
The problem with ChatGPT and programming is that it gets a lot right - but it is absolutely confident about things that it gets wrong, and you really need to know what your'e doing to spot this stuff - in which case you might as well have written it yourself. The colours above, for example. Completely wrong - not even close to matching actual TIA colours in either NTSC, PAL or SECAM
And although I haven't explored it, I doubt the LSFR works properly. And the earlier example, using location 0 to store the address of the indirect pointer for clearing RAM - well, that's not going to work either - you need to store that in RAM (from location $80 up) and in any case the clear is gonna zap that pointer too and cause a crash. So there's a whole lot of stuff that pops up using this system.
It's amazing, yes. Even more so that as I understand it, it's just a predictive word generator and doesn't have some "grand plan" to design in advance the stuff it spits out. Remarkable. But we need to be very careful about using/believing what it tells us.Totally agreed. The most impressive thing for me about GPT is the natural language parser and it'll be an excellent tool to talk things through with - I've done so to help clarify my understanding on various topics. But unless you know what you're doing already, the results of such a discussion could be awful. Consider this: we who are familiar with 2600 programming can identify the errors in the above cases. Is it not reasonable therefore to assume that it makes similar errors on every other topic?
The real danger is when politicians start using this to make decisions and the people believing that it's some sort of gospel because it's come from "the AI".
-
1
-
-
1 hour ago, Andrew Davie said:
"STX $80,x" does not exist but otherwise it's doing well.
It's fun and impressive but that kind of mistake just demonstrates to me the GPT-4 isn't useful for serious work. It's labelled the code "ClearRAMLoop" but it's not doing that, even if "STX $80,x" was a valid instruction. It's horribly misleading.
Still, I'll be interested to see where this goes next (Quadraslide and GPT) 🙂
-
4
-
-
26 minutes ago, splendidnut said:
Same for me. Which is to be expected because I don't see anywhere to set the video resolution / refresh rate for full screen mode within Gopher. So that means that Full-screen mode is basically the same as Full-sized Window mode.
Correct. Full screen mode in this case is SDL's FULLSCREEN_DESKTOP which is really just a borderless window.
-
What is performance like when VSYNC is enabled and the emulation is in full-screen mode? Full-screen mode can be toggled with F11.
-
Just now, Dionoid said:
Immediate updates make a big difference, and it seems the speed is very close to running on an actual Atari 2600. However it seems to skip frames a few times a second.
But yes, much better on my Windows machine.
Thanks. I need to setup a Windows machine so I can investigate this further. It seems both you and @splendidnut have similar issues. Ideally you'd be running with VSYNC enabled.
@johnnywc@Al_Nafuur have you noticed this issue on your Windows machines?
-
6 minutes ago, Al_Nafuur said:
I was able to build with:
git clone https://github.com/JetSetIlly/Gopher2600.git cd Gopher2600 brew install go brew install pkg-config brew install sdl2 brew install freetype2 make release
@JetSetIlly are there any other package dependencies?
Gopher2600 seems to work fine on my MacBook now, but the Zelda binaries I have build don't work.
I'll implement a better fix but for now, you can comment out lines 61-63 in the file hardware/memory/cartridge/mapper_3eplus.go
if len(data)%cart.bankSize != 0 { return nil, fmt.Errorf("3E+: wrong number of bytes in the cartridge file") }That seems to work.
-
1
-
-
Just now, Al_Nafuur said:
you might want to add gopher2600 to Homebrew, so the it can be easily installed/updated via brew.
Hmm. That might be a good idea. I was going to wait until v1.0.0 is released before doing that kind of thing. The other option is to get github to build the binary with a github "action" but I've never investigated it fully.
-
1
-
-
Just now, Al_Nafuur said:
👍
Just when I finished building myself. I still need an emulator on my traveling MacBook. How do I install gopher2600 on MacOS?
I can't build binaries for the Mac unfortunately so I don't distribute binaries on the github page. Both @Andrew Davie and @SpiceWare can build binaries for the Mac though. Hopefully, they will see this and share their builds.
-
-
15 minutes ago, splendidnut said:
My refresh rate is set to 75hz. So yeah, there's probably quite a fight going on trying to keep things in sync when VSync is turned on.
I usually run with a 60Hz refresh rate because that works best with NTSC ROMs with flicker ROMs. But I've just tried with a 75Hz refresh rate and it seems to run okay. Turning VSYNC off causes CPU usage to actually go up. So there's definitely a difference between how Linux and Windows are treating the display.
It's something to think about.
-
7 minutes ago, splendidnut said:
Yes, so maybe the framebuffer needs to be larger to hide the artifacts for those effects.
Hmm. Maybe. I'll look into it.
7 minutes ago, splendidnut said:I played around a bit and for some reason, turning OFF vsync (switch to Immediate Updates) fixes the issue and decreases CPU usage.
Interesting. VSYNC is something I've struggled to get working well in all instances if I'm to be honest, so there might be a clue here.
What's your monitor's refresh rate?
@Dionoid does setting VSYNC to "immediate updates" solve your problem?
-
1 minute ago, splendidnut said:
ROM selector is fine. It would be nice to be able to access things from a main menu; the debugger has it but it doesn't show for regular emulation mode. When in emulation mode, the Tab key shows the ROM selector, but it would be nice if it showed the menu instead of or in addition to.
Interesting idea. I'll play around with it this weekend
1 minute ago, splendidnut said:The issue with the mouse cursor is probably tied into how your program handles the Windows Event loop. I'm guessing MouseMove events are piling up and overwhelming the event processing code.
Maybe. I don't have the issue here but I'm not using Windows and don't have access to it. I'll take another look at it though.
17 minutes ago, splendidnut said:Here's a screenshot trying to capture the artifacting:
I can see it. Very strange. Does this only happen with CRT effects enabled?
-
19 minutes ago, JetSetIlly said:
Can you highlight the areas where you see the artifacts?
Thinking about this some more, I think you might talking about the interference option in the CRT effects.
-
4 minutes ago, splendidnut said:
I gave this emulator another try today.
Thanks for taking another look, it's changed significantly since you last commented.
4 minutes ago, splendidnut said:I like how I can just start it and load a ROM via the GUI now. The GUI still needs a bit of work though...
Do you mean the GUI for the ROM selector? If so, I agree. I've not done much work on it at all really. I'll revisit that part of the project this weekend I think. Do you have any suggestions for improvements?
4 minutes ago, splendidnut said:the only way I could find to edit the CRT preferences was by having the debugger view open.... and then exiting that to see the results. Is there a reason why the menu isn't shown / easily accessible from the regular emulation view?
The Preferences window can be opened with F10 when in playmode (regular emulation mode)
The full list of hotkeys is on the project's GitHub wiki. https://github.com/JetSetIlly/Gopher2600-Docs/wiki/Hotkeys
4 minutes ago, splendidnut said:I ran Paint The City as a test and there seems to be some strange artifacts with the right most playfield pixel column and the last line of the bottom road section.
I'm trying PaintTheCity NTSC 20220224 and I can't see any real differences between the Stella and Gopher2600 emulations.
Can you highlight the areas where you see the artifacts?
4 minutes ago, splendidnut said:Also, it just barely fits on the screen... is there an option to change the number of scanlines visible?
There isn't. However, in the debugger, you can "uncrop" the screen. This shows how the screen fits into the wider TV frame. The gray dotted lines indicate the top and bottom VBLANK areas and when HBLANK is turned off. The purple dotted line is the most recent VSYNC scanline.
4 minutes ago, splendidnut said:I did notice that the emulator seems to struggle with performance when the mouse cursor is moving over it, which seems a bit odd.
It's hard to comment on that because I don't see that effect here and nobody else has noticed it. I'll note it down as an issue though.
Out of interest, what specification is your computer's hardware?
Like us on Facebook
Follow us on Twitter
AtariAge on Instagram
Watch us on YouTube
Chat on Discord
In dasm, how do I correctly specify an include directory, located at a different directory inside the file's parent directory (relative path), from the command line?
in Atari 2600 Programming
Posted · Edited by JetSetIlly
The following should work. Note that the file you are assembling is specified before the options.
dasm program-1.asm -I../includes -f3 -oprogram-1.bin