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

It is ambitious but it's worth trying. I plan to start looking at it this summer, time permitting.

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. @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.

LOL

Haha. I know literally nothing about the format so maybe I have been a bit hasty 😆

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.

Well, the ROMs load but they don't seem to do much. The emulator can run Moviecart files.

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.

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. https://github.com/JetSetIlly/Gopher2600/blob/14e39086971b69575a149ce8235147ad65c6e56a/macro/macro.go 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?

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.

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.

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".

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) 🙂

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.

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?

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.

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.

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.

zelda.bin zelda_PAL60.bin

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.

Hmm. Maybe. I'll look into it. 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?

Interesting idea. I'll play around with it this weekend 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. I can see it. Very strange. Does this only happen with CRT effects enabled?

Thinking about this some more, I think you might talking about the interference option in the CRT effects.

Thanks for taking another look, it's changed significantly since you last commented. 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? 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 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? 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. 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?