From: Fred <fr...@sp...> - 2012-08-13 12:53:12
|
Hi Alex, On 13/08/2012, at 6:35, Alex Badea <vam...@gm...> wrote: >> There are a couple of design choices where I'd like to ask for advice. >> >> 1) How do we implement the floppy-flavoured IF1? >> 1A) implement a whole new peripheral type, with its own paging routines, etc. >> 1B) add a switchable mode to the existing IF1 code, allowing to choose >> between microdrive and floppy >> >> 2) Should we create new machine types for these clones? >> 2A) Yes (presumably one for each model) >> 2B) No, we would simply have some peripherals which can be manually >> enabled on top of spec48 >> >> Any and all other feedback is greatly appreciated. > > For now, I took the easy way out and prototyped a patch series[1] for > solutions 1B and 2B. This is pretty much full HC90 (non-CP/M) > support, except for saving IF1 FDC state in snapshots. I think the most proper way would probably be to have new machine types for the various HC clones as the timings if nothing else are almost certainly slightly different to the Sinclair 48K. With respect to the IF1 options the best way really depends on how the code ends up looking after the change. Generally we would take the approach of modularising the code to the point that both peripherals can share the appropriate code. > Alex Badea (15): > upd_fdc: implement Terminal Count support > debugger: add support for setting IM and IFFs > gtk debugger: use MEMORY_PAGE_SIZE instead of hard-coded 4k > disk: allow reading/writing mgt layouts of 80x16x256 and 40x16x256 At least these patches look applicable to "core" Fuse, do you mind if they get committed? I think that the HC clones could be added too assuming the code is clean and complete. With respect to 1K page sizes, Phil made the following comment about having regions smaller than 4K: > My concern here is that this sort of scheme would end up hitting the > readbyte_internal() performance - the only way I can see of implementing > a scheme like this would be to have a "contains small chunks" flag on > every page, which would then have to be checked on every read (as well > as every write, but that's already a much more heavyweight operation > than the inlined macro that is readbyte_internal()). > > As an aside, if we did go down this route, it may be worth increasing > the default page size back up to 16K. However, that's a decision for > much later down the line. > > If anyone has any ideas how we could implement a scheme like this > without hitting the readbyte_internal() performance, please shout! Do you have any thoughts or measurements of the performance impact of your change? Thanks, Fred |