Fun things to do with an MC68EC020....

[Nasta]

BTW I will soon add 8 Bit Aurora mode in 1024x768 to the Q68.

Just for info, I'm reconsidering this, because it turned out to bloat SMSQ/E size a lot.

As far as i have seen, isn't there 32M of RAM on board? I am sure SMSQ/E still remains tiny compared to today's standards...

[Peter]

It does, but I hate to spend more than the whole Minerva OS size for that single, additional screen mode!
For my personal taste, SMSQ/E has been bloated with many other features already, that I will never use, and would rather have seen separate from the core OS. It gets larger and larger, because it is mainly run on emulators, and somehow I don't feel like growing the core OS over 300 kB for a little machine like the Q68.

I hesitate to do unpaid work that somehow contributes to bloating the OS further. Even if the Q68 had "only" the QL and Q60 highcolor modes plus 1024x768 MODE4, it is still a nice machine.

[mk79]

As far as I remember, it was applications that would attempt writes to the ROM addresses. OS code is well behaved and in any case, self-modification is a no-no for any multitasking OS, but this is no wonder as we know the people who wrote it, and they all know very well what they are doing.

But I agree the point maybe moot - it is highly likely rather ancient software may be at fault, or something made by an old and buggy version of a compiler?
I do remember that Miracle spent quite a bit of money having to replace the INGOT CPLD on early GoldCards because of this.

For what's it worth, QPC never had write protection for the ROM space, in fact it doesn't have any ROM space, all is RAM. But my target was not 100% compatibility with old software, like QemuLator for example, but a modern SMSQ/E machine which didn't need to care about very old games etc.

Marcel

[mk79]

It does, but I hate to spend more than the whole Minerva OS size for that single, additional screen mode!

The 8-bit CON driver has 30kb of code, so not exactly more than whole Minerva. This includes a copy of PTR_GEN for this mode, which is roughly 20Kb. Sure, perhaps one could do the PTR_GEN part more generically, but that is a lot of work for saving 10kb or so and would probably make the whole thing a lot slower.

For my personal taste, SMSQ/E has been bloated with many other features already, that I will never use, and would rather have seen separate from the core OS.

Like what?

It gets larger and larger, because it is mainly run on emulators, and somehow I don't feel like growing the core OS over 300 kB for a little machine like the Q68.

This doesn't have anything to do with it running on an emulator. With SMSQ/E you get:
- HW-init plus OS core (~15kb)
- OS messages, keyboard tables and SBASIC strings in FOUR languages (~15kb)
- SBasic (~37kb)
- SBasic procedures (~27kb)
- DV3 driver (~25kb)
- Display driver including PTR_GEN (between 30 and 37kb depending on the mode)
- WMAN (~19kb)
- High colour system sprites (~15)
- HK 2 (~12kb)
- Home thing (~2,8kb)
- Recent thing (~5,2kb)

I don't really see much bloat in there. The home thing is something that should really be included in the OS. You can get rid of the system sprites and the recent thing, but apart from that... compare that to QDOS+TK2+PTR_GEN+WMAN+HK2+WIN driver+FLP driver + RAM driver+Lightning and you get a lot of KBs, too.

I hesitate to do unpaid work that somehow contributes to bloating the OS further. Even if the Q68 had "only" the QL and Q60 highcolor modes plus 1024x768 MODE4, it is still a nice machine.

The driver already exists, no matter what you do. In your case I'd much rather get rid of the low-res Q60 mode, because as I already wrote privately, for me the age of 640x480 or whatever low resolutions is over, but that's of course your call.

Marcel

[Derek_Stewart]

Hi Marcel,

Is it possible to have PTR_GEN, WMAN, HK, HOME thing, RECENT thing, Sprites loaded at boot time, or loadable as modules, instead of a single operating system.

Oh, yes, language loadable as a module instead of combined in the OS core.

Sometimes I like not use the Extended Envoirnment, bit this maybe a step backwards

[Peter]

The driver already exists, no matter what you do. In your case I'd much rather get rid of the low-res Q60 mode, because as I already wrote privately, for me the age of 640x480 or whatever low resolutions is over, but that's of course your call.

That would not bring any benefit. Neither on hardware side, as the highcolor logic for Q60 mode is needed for 1024x512 anyway. Nor on OS size. Nor on workload, since it is completed.
I was using this mode yesterday, I like it for this little machine and especially for the 8" monitor I have.

As for the other points: I do have a different figure of roughly 50 KB for only adding the Aurora mode. Other example, SMSQ/E has outgrown the standard Q60 EPROM (now requiring to boot the machine twice unless you replace the EPROMs with larger ones) and except for the commandline history, that size increase did not come from something I would probably miss inside SMSQ/E. Taking the community viewpoint, I find the SMSQ/E size increase fully okay, because those who did the hard work maintaining it, need to have their fun with features they like!

But here the point was, where I spend my own work, and that depends also on personal taste.

Update: 50 KB was the "library" length of the Aurora driver, fully compiled it shrinks to 30 KB indeed.

[Nasta]

Just a short return to the original topic:
After some peering into the various datasheets:
70ns static RAM will just barely do zero wait state on a 68EC020 up to 25MHz.
55ns static RAM can do zero wait up to around 33MHz.
In theory some MHz can be had by decoding the RAM slightly differently. The thing with the EC020 is thatt he addresses are synchronous to the clock but you only have ASL to tell you it's actually foing to do something on the bus, which lasts 2 clocks out of 3, which is 80ns, adding delays and setup times, 70ns just barely makes it (and only because address lines are valid before ASL)
It is well advised to use as dense parts as one can afford, because the number of pins the CPU has to drive grows quickly.
For instance, the most cost effective SRAM is 512k x 8, for 32-bit width you need 4, which is already 4 loads on the address lines, although only 1 load on the data lines - but it's only 2M of RAM. For 12M you get to 6 loads per data line but 24 loads on the address lines. If 70ns SRAM was used for this, it would impose quite alot extra delat even with very careful layout, and using a buffer wold make it worse since it adds delay to begin with.
On the other hand, using 1M x 16 parts, you need two per 4M or RAM, and it's two loads on the address lines and one on the data lines. 12M will be 6 loads on the address lines and 3 on the data lines. When you compare prices but add the speed benefit (higher density SRAM is also faster) and less cost of PCN realestate, it's likely it will come out roughly the same price.

[mk79]

Hi Marcel,
Is it possible to have PTR_GEN, WMAN, HK, HOME thing, RECENT thing, Sprites loaded at boot time, or loadable as modules, instead of a single operating system.

Yes, that is called QDOS. I don't want to go back there, really.

Speaking of SMSQ/E, you can remove WMAN, HK, HOME, RECENT and SPRITES just by altering the line that concatenates the modules. PTR_GEN is built into the CON driver.

> Oh, yes, language loadable as a module instead of combined in the OS core.

OK, but with the default set to German, then. It's easy to say for you English guys because that's usually the default anyway and incredibly annoying for everybody else.

Marcel

[mk79]

That would not bring any benefit. Neither on hardware side, as the highcolor logic for Q60 mode is needed for 1024x512 anyway. Nor on OS size. Nor on workload, since it is completed.
I was using this mode yesterday, I like it for this little machine and especially for the 8" monitor I have.

1024x512 is okay in terms of resolution, but more on the minimal side.

Other example, SMSQ/E has outgrown the standard Q60 EPROM (now requiring to boot the machine twice unless you replace the EPROMs with larger ones)

I can see how this can be annoying. Three possible solutions:
- Replace the line "dev8_iod_con2_sprite_hc_lib" with "dev8_iod_con2_sprite_ql_lib" in "WIN1_smsq_q40_sysspr_link". That might already be enough for Q60.
- Enable sprite compression on the HC sprites. I guess I implemented sprite compression later, so the default sprites are still uncompressed. Not sure if that gives enough space, but I'll look into that in any case
- Implement a simple compression algorithm for SMSQ/E modules. They are copied from ROM to RAM anyway, so why not uncompress them on the fly...

Marcel

[Nasta]

- Implement a simple compression algorithm for SMSQ/E modules. They are copied from ROM to RAM anyway, so why not uncompress them on the fly...
Marcel

Good idea for any code that is not executed from it's original storage...
BTW thanks for the data on ROM space protection, if anyone should know...