Menu
▾
▴
[fuse-emulator-devel] [ fuse-emulator-Patches-937338 ] Add Interface II support
|
From: SourceForge.net <no...@so...> - 2004-05-13 12:24:07
|
Patches item #937338, was opened at 2004-04-18 14:20 Message generated for change (Comment added) made by pak21 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=596650&aid=937338&group_id=91293 Category: None Group: None >Status: Closed >Resolution: Accepted Priority: 5 Submitted By: Fredrick Meunier (fredm) >Assigned to: Philip Kendall (pak21) Summary: Add Interface II support Initial Comment: This patch adds Interface II support. I am not sure whether it is worth introducing a capability or some other flag to specify whether the IF2 is installed on the current machine. Not all machines were physically compatible with the IF2, but it uses no ports and is passive so the only effect would be to disable the menu... Comments are welcome! ---------------------------------------------------------------------- >Comment By: Philip Kendall (pak21) Date: 2004-05-13 12:24 Message: Logged In: YES user_id=29214 And the rest applied. ---------------------------------------------------------------------- Comment By: Fredrick Meunier (fredm) Date: 2004-05-13 02:43 Message: Logged In: YES user_id=11017 D'oh, updated patch and missing files attached ---------------------------------------------------------------------- Comment By: Philip Kendall (pak21) Date: 2004-05-12 15:03 Message: Logged In: YES user_id=29214 if2.c and if2.h are missing from the patch :-( ---------------------------------------------------------------------- Comment By: Philip Kendall (pak21) Date: 2004-05-12 12:27 Message: Logged In: YES user_id=29214 I've just applied the bits of this patch which implement the memory mapping changes. ---------------------------------------------------------------------- Comment By: Fredrick Meunier (fredm) Date: 2004-05-02 11:06 Message: Logged In: YES user_id=11017 This is an updated version of the patch. It doesn't have anything to handle TR-DOS ROM as I think that it is incompatible with the Interface II anyway, so I have disabled it for the Russian clones. As the Interface II didn't work with the +2a/+3(e) I've disabled it for those machines as well. I would like to see support in the peripheral code to handle conflicting peripherals, maybe by registering which resources are required (ports, romcs line etc.) and offering a dialog that handles enabling/disabling peripherals. There could also be a hook in the peripheral code to allow memory mapping adjustments to be registered. ---------------------------------------------------------------------- Comment By: Philip Kendall (pak21) Date: 2004-04-22 22:49 Message: Logged In: YES user_id=29214 I like (1) as the way of doing things. If you want to code it, that's great :-) I think it may be slightly easier than you've made out: changes to last_byte[2] are already dealt with in memory_map_home[], so all we need to know is which of home/dock/exrom/random peripheral 1/random peripheral 2 (including the TRDOS rom) is paged in. (I'm not sure what we do with 'conflicting' peripherals: eg both the ZXATASP and the If2 use ROMCS, making them incompatible on a real machine, but I see no reason we can't implement both at the same time). ---------------------------------------------------------------------- Comment By: Philip Kendall (pak21) Date: 2004-04-22 14:33 Message: Logged In: YES user_id=29214 The memory leak will be fixed if you use the new memory_allocate_pool() to get (emulating machine) memory for RAM/ROM/etc pages; this keeps track of all the memory allocated for that (Spectrum reset to Spectrum reset) 'session' and will clean itself up on reset. ---------------------------------------------------------------------- Comment By: Fredrick Meunier (fredm) Date: 2004-04-22 13:12 Message: Logged In: YES user_id=11017 I see the problem with ROMCS. There are a couple of other choices that come to mind aside from trying to remember the previous memory map before ROMCS was twiddled (problematic in the face of other paging activity while ROMCS is enabled?) 1) Restructure the various machines code to have a memory map function that sets the memory map correctly based on the current settings (i.e. last_byte[2] and scld_last_hsr), and have the port write functions save the port values and then just call the memory map function. This allows us to cope with ROMCS being toggled by just running the mapping function for the current machine again (do any machines have different mappings for the same static port and ROMCS values? I don't think so...) 2) Have the memory_map structure have room for ROMCS overrides and select the right thing based on the current value of ROMCS (the approach taken by the ZXATASP patch?). I don't like this as much as the other approach. I've brought the patch up to date aside from the same memory leak as the dock and the ROMCS issue above, if you are happy with 1) above I'll code it up. ---------------------------------------------------------------------- Comment By: Philip Kendall (pak21) Date: 2004-04-21 22:31 Message: Logged In: YES user_id=29214 I agree completely that the ROMCS bank is just another bank like the Timex DOCK and EXROM; the problem which I think we may hit with the ZXATASP/ZXCF if not the If2 is how to handle paging the ROMCS bank out, rather than paging it in. Essentially, we have to remember the previous configuration and restore that, which isn't handled at all nicely yet. But then I haven't thought of any better ways to handle it... As for sizeof( libspectrum_byte ), there _might_ be an embedded system or something out there with 4-bit chars. Unlikely, I guess, but I see no loss whatsoever in putting it in. ---------------------------------------------------------------------- Comment By: Fredrick Meunier (fredm) Date: 2004-04-20 11:58 Message: Logged In: YES user_id=11017 1) I've just commited #932893 which changes all the memory mapping code, so a significant portion of this patch won't work. It'll be sorted out by this weekend :) 2) We need to think about a generalised mechanism for handling /ROMCS as that's also needed by the ZXATASP and ZXCF interfaces. I am having a closer look at those patches now, more comments to come. My opinion is that the extra space made available by the /ROMCS line is very similar to another sideways memory bank like the Timex banks. I guess we should also allow for the +2A/3 which have /ROM1OE and / ROM2OE to select two different ROMs (I think). (Style nitpicks) 3) sizeof( libspectrum_byte ) isn't guaranteed to be 1, so that's needed in any malloc() calls. That would imply that sizeof(char) < sizeof(libspectrum_byte) which I find a bit hard to fathom :) I assert that sizeof(libspectrum_byte) is guaranteed to be 1 for all platforms that have a reasonable C environment :) 4) I'd like to keep to the convention that any global symbols defined in <foo>.c are called <foo>_something as much as possible (romcs_memory_map). No problem. ---------------------------------------------------------------------- Comment By: Philip Kendall (pak21) Date: 2004-04-19 21:08 Message: Logged In: YES user_id=29214 Fundamentally, I've got no objections to this idea, but I see a few problems (in approximate order of seriousness): 1) I've just commited #932893 which changes all the memory mapping code, so a significant portion of this patch won't work. 2) We need to think about a generalised mechanism for handling /ROMCS as that's also needed by the ZXATASP and ZXCF interfaces. (Style nitpicks) 3) sizeof( libspectrum_byte ) isn't guaranteed to be 1, so that's needed in any malloc() calls. 4) I'd like to keep to the convention that any global symbols defined in <foo>.c are called <foo>_something as much as possible (romcs_memory_map). ---------------------------------------------------------------------- Comment By: Fredrick Meunier (fredm) Date: 2004-04-19 13:01 Message: Logged In: YES user_id=11017 Attached is an updated version of the patch, I'll check it in this weekend barring any unfavourable comments. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=596650&aid=937338&group_id=91293 |