Posts by robinsonb5

Quote from el_pasi

Just tested and Logitech PS/2 mouse didn't respond. OSD counted from 9 Mouse Debug: to 4 Mouse Debug and probably then froze, since there's not much happening in the last 30 minutes When it counted to 4 and froze there appeared letters TTT to second row of OSC-screen.

Thanks, that's really useful. If you're not seeing any numbers (other than the countdown) before the "TTT" appears on screen, then the mouse isn't responding to the reset command - so Jens's first hint about the communication-inhibit time is probably the key.

Quote from el_pasi

Alastair: Unfortunately didn't solve problem, still doesn't work with Logitech PS/2 optical mouse. Then I tried with older HP PS/2 optical scroll mouse, and that works at least with newest core. HP-mouse works with Minimig too, and most probably with C64-core. I'm a bit loss now, what is different with Logitech-mouse, why it isn't responding with ST-cores.

Patrick: Thanks for confirming

Thanks for testing - could you give this version a spin, please?

If it still doesn't work, could you try pressing Ctrl and Esc simultaneously. It should open the OSD, attempt to reinitialise the mouse, and dump the mouse's responses to the OSD. Could you let me know what you see, please?

(The Atari might go a bit nuts while the test is progressing - if so just ignore it!)

That is very cool!

Quote from Jens

Edit: Hmm... we seem to not exactly talk about the same thing: I am assuming that the whole floppy/MFM image has already been loaded to SD-Ram. You seem to want to load tracks/sectors on the fly from SD card. I don't see that working. We do need an SD-Ram buffer for the whole image. So please use the more precise terms "SD-Ram" and "SD-card" instead of just SD, so we know exactly what you're talking about

I don't see why loading data on the fly from SD card shouldn't work (with a BRAM-based buffer / FIFO in between to cover the gaps while we read the next block from SD card). It's what we're currently doing, and we're not talking about a crazy increase in bandwidth here. (The same approach works for streaming CD audio in the TGFX16 core, for instance - though admittedly with a bigger buffer and much looser random access requirements).

Given that the Amiga can have up to four drives, if each image is more than 2 megabytes in size we're certainly not going to want four entire images in SDRAM. A track at a time might be more practical - there should be plenty of time during a head step to fetch a new track's worth of data - or at least enough for the read process to begin.

Thanks for the PS/2 tips - I am currently sending the knock before enabling streaming mode, but I'm not yet repeating the reset command if BAT doesn't arrive - that may well be the key. I'll have another go this evening after work.

Quote from Jens

Let's wait for robinsonb5 to comment on available CPU/MCU time of his menu engine,

The 832 CPU and control module is currently clocked at 50MHz, and manages a shade under 7 DMIPS. It's deliberately clocked at well under its theoretical maximum speed to avoid adding timing pressure to the guest cores.

(The goal with the CPU was always to be small, both in terms of logic and code density, rather than to be fast. Because of that, it's not well suited to decompression workloads. Shifting, in particular, is slow - the usual optimisation of replacing multiplies with shifts applies in reverse here!)

Currently the host CPU has "custody" of the SD card, so it's responsible for loading the ROM at bootup and for handing data on-request to the disk emulation. It's also responsible for passing joystick events to the core. With some cores it handles keyboard events, too - but MiSTery has enough provision for PS/2 devices that I've given it direct access to the physical keyboard and mouse.

My goal with most of the MiST cores I've ported to TC64 has been to do it as non-invasively as possible - to avoid modifying the upstream core any more than strictly necessary, so that it's easier to keep in sync with upstream changes, and so it's possible to merge the codebases in the longer term. (Gyurco and I have already collaborated closely with both Minimig and TurboGrafx16, and both of those now have a shared repo for MiST and Chameleon64.)

Making the DeMiSTify wrapper as transparent as possible to the guest core means keeping the firmware as small and streamlined as it can be, since a lot of the cores use up most of the FPGA's block RAM.

For most of the cores so far the firmware, working RAM and stack have fit within just 12k. (TurboGrafx16 needed 24k because of the CD image support and bin/cue parsing.) The port of MiSTery currently needs a shade under 14k - but that's likely to be nearer 20 once hard drive images and the C64 keyboard are supported.

There's currently enough free block RAM in this core for the firmware to grow to 30k so there's plenty of headroom at the moment. (I'm reluctant to extend into SDRAM since it means more invasive changes and slower execution - but it's nonetheless possible: Minimig already does it that way, and I believe it will be necessary for the Archimedes core.)

As for a new floppy image format, provided there's a straightforward way of mapping from track and sector to file offset I don't see it presenting too many difficulties for the firmware. If large decompression buffers or index tables are needed then it'd be a different story.

Quote from el_pasi

Alastair: That's good, and core is already in very good shape. Have been able to play a bunch of ST-games already

There is a few programs with which it is possible to convert MSA to ST-files. I converted whole automation-collection with MSA Converter v2.1 (by Zorg). Probably there is no way to convert from STX to ST, because STX has copyprotection infos etc.

Could you try this version, please? (If anyone else wants to try it, please note it's for V1 hardware. A v2 version will follow if it turns out to solve the problem.)

Quote from JJXB

Both mouse and joysticks appear to be working on v2 hardware but the options for the core don't save in any way when the TC is powered off and on again. and the stx files i've got don't seem to show up in the file browser, only the st files.

That's right - there's no support for saving the settings yet. I have to think about the best way to handle options saving within the confines of the compatibility framework.

Neither .STX files nor .MSA files are supported - I don't know whether it'll be possible to support those in future, but as far as I know they're not supported by the upstream core.

Quote from el_pasi

Patrick: Just curious, that does mouse work in your setup with ST-core? You seem to use TC64v1 standalone. I do too and mouse doesn't respond in my setup. It works with other c64&minimig, but not with ST.

I have some ideas for debugging this - and I have a few more PS/2 mice I can test on my V1 Chameleon - so don't worry, we'll get that working in due course.

Changing the memory size should work, but the ROM only checks for the RAM size on a cold-boot - so a soft-reset isn't enough after changing the memory size. You have to trigger a hard-reset instead.

To trigger a hard reset, highlight the Reset menu option, and instead of tapping Enter, hold it for a second or two, until the core resets.

The extra memory should then be recognised.

Hmmmm, OK - I'll have to try and think of a way to debug that. (Just to be sure, this is a PS/2 mouse, not an Amiga mouse, yes?)

In the meantime, this version of the core should fix the joystick issues:

http://www.retroramblings.net/…ery_TC64v1_20210904_2.zip

Thanks for testing - I will investigate.

Does the mouse not respond at all, or does it move erratically?

Quote from Jens

Does the core use the MIDI ports of the new Docking Station? I'm not an Atari person, but when it comes to ST, MIDI pops up in my head.

It does indeed - getting MIDI working was high on the list of priorities!

Here's a first version of the newly-ported Atari ST core for Chameleon.

http://retroramblings.net/?page_id=1705

This is a port of the MiSTery core from the MiST platform. It doesn't yet support all features of the upstream core, so there's no support as yet for hard disk images, or for the C64 keyboard - though I do plan to add both in the near future.

Have fun!

Quote from Tobias

Yes, thats the most annoying thing.... i adjusted it, then pressed START and damn, its far to the right again =)

check this (Is that 20 years old? damn!)

Currently it just buffers two lines of video and seems to be pretty much at the "gameboy"'s mercy when it comes to generating sync. The SDRAM's not currently too congested, so it might be possible to move to a proper framebuffer in future.

The game looks really cool!

Quote from Tobias

Cool stuff! Have to try this asap

(There seems to be some copypaste error on the blog page...referring to the NES core :))

Edit: awesome. i tried it with the one Gameboy Color title i was involved in that actually got published - works perfectly

One thing that is a bit weird is, although my Monitor can display the image fine - the autodection will mess up the horizontal position so there is a considerably large black area on the left (something like a fifth of the screen or so).

Display More

Thanks for spotting the copy-paste errors - fixed now. (The wordpress text editor is a bit flaky sometimes, and when you delete a chunk of text it sometimes gets merged into the previous paragraph instead!)

So which title was that?

I shall look at improving the screen output at some point - it behaves a bit oddly here, too - it's somewhat narrow, and gets clipped slightly at the bottom of the screen. Also any time the game touches the video mode register the monitor ends up resyncing. So there's definite room for improvement there.

I've just released a port of the Game Boy core for Chameleon64 - have fun! https://www.patreon.com/posts/55526660

(Please note: to play GameBoy Colour games you'll need a suitable BIOS file, named gbc_bios.bin, in the root directory of your SD card.)

Not just one, but two more cores in the works...

https://www.patreon.com/posts/54872832

https://www.patreon.com/posts/55446183

Quote from Jens

The key at that position is CLR/HOME on the C16. And I guess that robinsonb5 had trouble detecting the C64-side NMI pulse to turn that into a CLR/HOME key on the C16 core.

Yes, exactly that. The keyboard mapping was fairly straightforward, simple and clean apart from that inconvenient detail!

Quote from dbugster

I finally got around to the core Love it ! Are dedicating a ps/2 keyboard to it due to the slightly different layout. And I discovered that C16 doesnt have a Restore button

Glad you're having fun with it! D64 support is basically working now so there'll be an update soon.

The restore key caused me some grief, because of course it's not a "proper" key on the C64 so I have to catch the momentary pulse on the restore key and widen it for that one particular key in the C16's matrix. (The c16 makes room for the extra key in the matrix by combining the two shift keys - they're not separate like they are on the C64.)

Quote from SID-6581

What the first entry "ATAPIismajik" means is not clear to me.

All four hard files are integrated as a "disk image". After starting the HDToolbox, I was informed that there would be new HDDs. I then saved the hard drives that had "changed". After a restart, all four hard drives are now available. Thank you!!!

"ATAPIismajik" is just the module's internal name - I'm not sure why it's different from the filename, but it doesn't matter - as long as it gets loaded!

Glad to hear the problem's solved - have fun!

Sorry for not seeing your post on eab (I stopped participating there a while back.)

I'm no expert on using loadmodule / OS3.2 - but it will accept multiple modules on one line, so after modification your startup-sequence snippet would read:

Once Workbench has booted you can check that atapimagic is properly installed by opening a shell and typing:

> loadmodule list

Once you have secondary drives mounted in the menu, you should be able to see them in HDToolbox.

If your primary slave device is mounted in "Disk image" rather than "Filesystem" mode, then it will have a RigidDiskBlock (equivalent to the MasterBootRecord on a DOS drive) - and that block may have the "RDBF_Last" flag set. If so, the Amiga won't bother looking for any other drives after mounting that one. The cure for this is just to run HDToolbox. It will prompt you that drives have been added or removed, and make the necessary change to the primary slave device - so just click that device followed by "Save changes to drive".

Don't try and save changes to drive for any drives mounted in "Filesystem" mode - the RDB for such devices is faked on the fly, so there's nowhere to save it to.

(For convenience, the Minimig does automtically remove the RDBF_Last flasg on the primary master device's RDB, to avoid having to go through theses steps - I will look at making it do the same for other units.