search

davidgiven / cpm65

CP/M for the 6502
BSD 2-Clause "Simplified" License
261 stars 24 forks source link

request : Port this the the Neo6502 please #55

Open snakebyte69 opened 1 year ago

snakebyte69 commented 1 year ago

https://www.olimex.com/Products/Retro-Computers/Neo6502/open-source-hardware

davidgiven commented 1 year ago

Would love to (even though the RP2040 is capable of emulating the 6502 all by itself!). I just don't have one...

quincy451 commented 1 year ago

Don't have a Neo6502...give me an address at @.*** and I will get one sent out...cost to you...$0.00... Just trying to help everyone out.  

On Monday, July 24, 2023 at 04:32:06 AM CDT, David Given ***@***.***> wrote:

Would love to (even though the RP2040 is capable of emulating the 6502 all by itself!). I just don't have one...

— Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you are subscribed to this thread.Message ID: @.***>

davidgiven commented 1 year ago

Thanks very much --- that's very kind!

However, looking at the specs it seems there isn't any kind of onboard mass storage, which I'd need. Also, it looks like the device is mostly intended to emulate another platform? I see there's support for the Apple II. It's theoretically possible that the Apple II port should just work on it.

snakebyte69 commented 1 year ago

I'm also happy to send you a Neo6502 even if porting CPM65 is not viable, I'm sure you would something else interesting to do with it that you can make a video of. You can message me here https://agonlight.au

markjfisher commented 8 months ago

Adding my voice to those who would love to see a native port of cpm65 on Neo6502. What are the implications of running the A2 port of the Neo6502? How different, if it were possible, would porting directly to it be?

oliverschmidt commented 8 months ago

However, looking at the specs it seems there isn't any kind of onboard mass storage, which I'd need.

The device has neither a keyboard nor a pointer device nor a mass storage nor a network device nor a <....>. The idea is to see USB as the way to add any device necessary. The user is supposed to add a USB hub and add all desired peripherals to that hub.

So mass storage is supposed to be provided by a USB MSC (Mass Storage Class) device (aka thumb drive). The RP2040 on the Neo6502 runs the TinyUSB (https://docs.tinyusb.org/en/latest/reference/index.html) USB stack. At this point, TinyUSB has host support for:

The Reload Apple II emulator already uses this approach successfully to emulate an Apple II 32GB hard disk.

oliverschmidt commented 8 months ago

It's theoretically possible that the Apple II port should just work on it.

Not only theoretically. It works (of course).

oliverschmidt commented 8 months ago

Also, it looks like the device is mostly intended to emulate another platform?

It certainly is not! The problem is that the device is so flexible that people tend to have a bit of an issue to see where to start from. So doing an emulation was just the easiest way to get something going. But the developers on the Neo6502 Discord want to do different things with the Neo6502!

A super-quick background: I own a Neo6502 and I have contributed to the Reload Apple II emulator running on the Neo6502. Additionally I'm working with the RP2040 (incl. PIO) in another project pretty much since it appeared on the market. And finally I'm the maintainer of the Apple II C library of the cc65 toolchain since many years.

People interested in developing something on the Neo6502 are primarily after the "software defined hardware" aspect of the Neo6502. This interest has often to do with graphics. I'm advocating on the Neo6502 Discord for a native port of CP/M-65 to the Neo6502 for several weeks. My reasons:

So to me, CP/M-65 seems a quite natural choice for the Neo6502. And as there's no "native" environment so far for the Neo6502, CP/M-65 has here the opportunity to be not just "some alternative" to the original environment, but become the original environment.

And finally regarding running CP/M-65 via the Reload Apple II emulator... Of course all issues could be solved in one way or another by extending either CP/M-65 for the Apple II or by extending the Reload emulator. But at least from my perspective, it quickly makes much more sense, to go the direct route.

In general, CP/M-65 on the Neo6502 could leverage the "software defined hardware" approach of the Neo6502 by not having a BIOS implementation that adapts to the existing environment, but rather have the environment be adapted to the BIOS API so that about no 6502 BIOS code is necessary. I've followed this paravirtualization approach with my hard disk emulation for the Reload Apple II emulator. The whole block r/w code is this:

        LDA #MAGIC
        STA PARA|$10*SLOT
                        ; ABRACADABRA
        LDA RC_A|$10*SLOT
        LDX RC_X|$10*SLOT
        LDY RC_Y|$10*SLOT
        CMP #$01        ; SET CARRY IF A IS NOT 0
        RTS

See: https://github.com/vsladkov/reload-emulator/blob/main/src/devices/prodos_hdc_rom.S#L108-L115

All RAM visible to the 6502 is emulated by the RP2040. So the STA just triggers code on the RP2040 that reads the necessary parameters directly from that RAM and reads/writes the hard disk block directly from/to that RAM - sort of "Hyper-DMA". Only setting the 6502 registers/flags needs to be done via traditional 6502 code, as the 6502 isn't emulated but real.

Maybe it could/would be fun to implement a CP/M-65 BIOS that way... I suspect CP/M-65 for the Neo6502 could have the largest TPA theoretically possible...

davidgiven commented 8 months ago

That all seems pretty reasonable; although once you start going down the route of offloading functionality to the Pico, you eventually start asking questions like 'what about filesystem access?' and 'multiplication and division?' and 'what about floating point?' and soon you have the 6502 essentially acting as a scripting language for ARM code...

Is there an emulator?

oliverschmidt commented 8 months ago

At least to me personally there's a clear line: Everything having to do with I/O fits. Everything going into the direction of a co-processor doesn't. But it's likely a matter of personal taste where to draw the line.

And from the CP/M-65 perspective it seems obvious to at least me: Only the BIOS is machine specific, so only the BIOS makes use of any special machine capabilities. If people create CP/M-65 programs that only run on the Neo6502 because they make use of then that's their business.

And no, there is no emulator. That's primarily because there's no RP2040 emulator that would be able to emulate the RP2040 PIO hardware blocks.

davidgiven commented 7 months ago

Very belatedly: my last message may have sounded discouraging --- I'm more than happy to do a port, or to help someone else do a port, but I need access to hardware or an emulator!

I have someone else who's done a port to the Sorbus homebrew computer which also uses a RP2040 for the chipset stuff, and it uses faked-DMA to get data in and out of the 6502's memory, making the BIOS really small and fast. CP/M-65 works very nicely on it.

paulscottrobson commented 6 months ago

I'm working on the Neo6502 firmware which hopefully will be the standard for non-emulation. It has a proper emulator and supports SDCard and USB Key storage.

It's a completely clean machine, almost. OS Calls are by message passing, so it requires 16 bytes of memory somewhere. It's currently at $FF00 to $FF0F but is designed to be moveable (though it isn't yet). Not quite sure what storage interface you required ; at present it's very basic file load/save/directory but the code is all done via FatFS so extending that shouldn't be an issue.

oliverschmidt commented 6 months ago

My personal expectation would be that a CP/M-65 port to the Neo6502 leverages @paulscottrobson's firmware.

The only conceptual issue I see is that this firmware - as @paulscottrobson already mentioned - provides a file level mass storage access while CP/M-65 needs sector level mass storage access.

However, I presume that we all agree that it is very desirable from the end user perspective to stay with an FAT file system on SD Cards or USB Flash Drives. Therefore it seems unavoidable to introduce CP/M-65 disk images. And then the file level mass storage access fits again.

Of course it is necessary to provide calls to open a file and then read/write to any offset in the file (which are missing today) in order to have CP/M-65 use a disk image file in an efficient way.

I personally would consider it great to move the discussion of such topics to the Neo6502 Discord server.

davidgiven commented 5 months ago

It may be possible to do a CP/M port which uses a native filesystem; the BDOS would just translate CP/M system calls into whatever the native filesystem needs. The CP/M-65 emulator (https://github.com/davidgiven/cpm65/blob/master/tools/cpmemu) does this to allow running CP/M programs on the host operating system. The tricky part is deciding at what level to do the emulation. There are lots of CP/M programs which expect FCBs to contain meaningful data, so this would have to be faked somehow.

Re Discord: please, no! github comments are far more accessible, easier to track, and doesn't overload me with notifications.

oliverschmidt commented 5 months ago

Re Discord: please, no!

That's of course your decision, but you should have stated so because "everybody" was waiting for you to arrive on Discord in order to discuss the necessary details - a classic deadlock :-(

Now that this is sorted out...

davidgiven commented 5 months ago

I am actually on what I thought was the Neo6502 Discord server, and introduced myself there, but it seems to be completely dead (no activity for weeks). Investigating has shown that is is merely a Neo6502 Discord server. So I should now be on the wrong one.

I did just receive a Neo6502, but there's no cover note so I have no idea who it's from. I do have at least one other person who's offered to send me one so I will need to check with them to see if it's theirs.

@paulscottrobson That looks almost ideal. https://github.com/paulscottrobson/neo6502-firmware/blob/main/documents/release/api.pdf is the API documentation, right? My one concern is that I don't see anything like a file system API; the only operations listed are read/write file and to display a catalogue. Does anything exist yet?

oliverschmidt commented 5 months ago

Seems what you see matches what wrote before:

Of course it is necessary to provide calls to open a file and then read/write to any offset in the file (which are missing today) in order to have CP/M-65 use a disk image file in an efficient way. 😉

davidgiven commented 5 months ago

Oh, oops, you're right.

Looking at the RP2040 source, adding a generic file I/O layer doesn't look hard, but it would require careful thought about how it's actually supposed to work.

autismuk commented 5 months ago

No, there isn't. However the underlying tech is fatfs so you can have pretty much anything you want. It's a matter I understand of how you link the two. Adding something like stdio functionality is on the short term list, but given it doesn't really matter from my end it makes sense to consider it from yours. I'm not home till Tuesday btw.

The other thing is the API buffer is designed to be moveable. I did quite like the idea of possibly booting Cpm65 though. Either as an option or underlying. Basic can go anywhere. I'd have to check it's okay with the Pascal chap, but it probably could move permanently.