Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Internal_RAM fixed to 256K for MCL86+? #20

Open
HeathenUK opened this issue Jun 26, 2023 · 5 comments
Open

Internal_RAM fixed to 256K for MCL86+? #20

HeathenUK opened this issue Jun 26, 2023 · 5 comments

Comments

@HeathenUK
Copy link

Hi Ted,

Great work on all of these projects.

With the Teensy having 1024KB of RAM (albeit only 512KB tightly coupled) and with relatively mild RAM usage in the main accelerator, is there any reason we couldn't have Internal_RAM be 0x80000 or even 0xA0000? The latter would bust the tightly coupled RAM but should still fit?

Regards,

Greg

@MicroCoreLabs
Copy link
Owner

MicroCoreLabs commented Jun 26, 2023 via email

@HeathenUK
Copy link
Author

I wonder if there's any way to track DMA calls. Of course part of the point is that the 8088 is out of the loop...

In any case, I don't currently have any inbound DMA to worry about!

G

@MicroCoreLabs
Copy link
Owner

MicroCoreLabs commented Jun 26, 2023 via email

@HeathenUK
Copy link
Author

HeathenUK commented Jun 26, 2023

I suppose without access to the ISA bus signals not tapped by the 8088 you'd need to trap writes to the I/O ports for DMA control registers and channels 1 and 3 (and maybe 2, for compatibility with floppy drives)?

This is just me being slow but I hadn't actually realised how simple the 8237 DMA controller actually is in that regard: https://www.lo-tech.co.uk/wiki/8237_DMA_Controller

G

@HeathenUK
Copy link
Author

Related - I've just clocked that the various bits of runtime (mode==1) conditional code in the accelerated version are commented out. It looks like most of that is about ROM and RAM shadowing though?

I gather from this that the intended function now is to hard set mode = 1 at compile time rather than via serial at runtime? That makes sense especially re. ROM mirroring.

The only piece of code I'm less clear on which is now commented out is //if ( mode==1) clock_counter=0;, which I think is intended to drain the pseudo op cycle counter to maximise the acceleration?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants