Welcome, Guest. Please login or register.


Author Topic: Just started coding for the Enterprise 128 and have a couple of questions (Read 7334 times)

Offline ergoGnomik

  • EP addict
  • *
  • Posts: 1291
  • Country: hu
  • Stray cat from Commodore alley
I'm sorry to shout in from the sideline, but you made one assumption Sdw, and you guys didn't correct him, that on occasions may not be true. Namely that segments F8 to FB are always existing. There are, AFAIK, internal memory expansions that move the RAM area to completely different segments. Therefore it may occur that even if the machine has enough memory your program will crash. Although it is tedious as hell and a pain in the bottom, you should use EXOS at least until you map the actual memory configuration.

But please scream at me if I said something completely dumb.

Offline lgb

  • EP addict
  • *
  • Posts: 3563
  • Country: hu
  • æðsta yfirmaður
    • http://lgb.hu/
I'm sorry to shout in from the sideline, but you made one assumption Sdw, and you guys didn't correct him, that on occasions may not be true. Namely that segments F8 to FB are always existing. There are, AFAIK, internal memory expansions that move the RAM area to completely different segments. Therefore it may occur that even if the machine has enough memory your program will crash. Although it is tedious as hell and a pain in the bottom, you should use EXOS at least until you map the actual memory configuration.

But please scream at me if I said something completely dumb.

I think, you're right. What is fixed is the VRAM itself only, at the four last segments of the 4Mbyte addressing space of the machine. First of all, Ep64 does not have memory expansion at all in addition of that by default. I guess, it's even possible to have an EP64 expanded in a way that it has got 128K RAM at the end, but using different segments. Thus that machine is more or less an Ep128 after that (note: Ep64s has older EXOS versions as well, if I remember correctly) but not at the "usual" segments. Also, it's possible you have not-working segments (bad RAM etc) and should not be used, EXOS on "boot" may marks segments as "non-working" based on memory tests. And anyway, with RAM expansion solutions there are may of them, you can't be sure about the actual segment numbers, indeed! In theory some can even replace the internal memory expansion board of Ep128 to another solution giving more RAM but using different segment numbers, etc etc.

I agree, EXOS should be used to allocate memory! Even if the program does not use EXOS than anymore at all, at least at start-up it should. One solution can be some EXOS segment allocation calls (program should check if it fails for not enough segments etc, also the fact that segment number allocated is >= 0xFC if it's important to know VRAM/non-VRAM nature of the result, etc) at the beginning of the program and storing the segment numbers EXOS returned. Thus then you can use these segment numbers for ports 0xB0-0xB3 later and you may not need to "talk" with EXOS anymore, especially if program is not "EXOS friendly" (ie it won't exit "cleanly" but "cold" reset) then it's just needed to have your segments for RAM for the given machine which will run the software.

Some may argue with me, that Ep128 is more common, and segments F8-FB will exist on 99% of these machines, but somehow, I feel, it's not a too much extra to use EXOS at least _ONCE_ at the startup of your program, even if not any more later :)

Offline lgb

  • EP addict
  • *
  • Posts: 3563
  • Country: hu
  • æðsta yfirmaður
    • http://lgb.hu/
If we just assume that for my demo I will be a bit "mean" and skip the possibility to do a soft-reset etc. so you will need to power off the machine once you finished watching my demo.

One note:

You don't need to power-off, you can press the nice red button on the rear of the machine, ie reset :) It's actually a hardware reset, always. It just matter of software (EXOS), that EXOS checks system segment etc whatever (I really think Zozo and IsvanV know these much better than me), and may decide to interpret that as "software" or "warm" reset, passing the control back to you, etc etc, or doing full initialization of the machine ("cold"). If you "damage" the system segment by intent ie zeroing it, it will cause the reset button will do "cold" reset after all (since EXOS' check of system segment won't find any meaningful state there to be able to continue with). But don't forget that this "cold" and 'warm" reset is more a software decision of EXOS rather than being a hardware level notion/difference, the reset button itself causes hardware reset anyway. As far as I know at least, I am a bit lamer with these topics, I am afraid :)

Quote
We can also assume that I put a 'di' instruction somewhere at the beginning of my program, and I will not do an 'ei', or at least not until I have pointed to my own IRQs.
To me (in my admittedly limited knowledge) it seems then that there should be no risk of me messing up any EXOS stuff or expansions, since I have in essence taken control of the system, and no code that isn't my own is going to be run until the machine has been powered off?

Yes, or reset, in addition of power-off ;)

Yes, or you can have even your own interrupt handler so EXOS won't get the control. Just be careful: if you don't disable interrupts, you need to be sure, that the actual memory segment used as page 0 should have some meaningful code where Z80 would jump in case of an interrupt. By default it's some code to do the things of EXOS but surely, you can even overwrite that, etc. Or yes, you can just have disabled interrupts if you really don't need them anyway! Btw, you can even disable interrupts in the Dave chip level (not on Z80 level with 'DI') as it also acts as some kind of "interrupt controller", so it won't route any of the interrupt sources towards the Z80 regardless you disabled/enabled on the interrupts by Z80 with opcodes EI/DI.

Offline Zozosoft

  • Global Moderator
  • EP addict
  • *
  • Posts: 14722
  • Country: hu
    • http://enterprise.iko.hu/
But don't forget that this "cold" and 'warm" reset is more a software decision of EXOS rather than being a hardware level notion/difference, the reset button itself causes hardware reset anyway.
Reset button connected to the Dave RSTI input. The Dave generate short reset impulse to the system bus Reset line. Only one short impulse generated, don't depend of the pressing time of the reset button. This is important for the keep memory contents: on other systems where the reset button connected directly to the reset line, the Z80 halted until the button released, then no DRAM refresh!

The reset erase Dave registers, then segment 00h (ROM0 of onboard ROM) paged to the all Z80 pages. Z80 also reseted, then it is start execute the ROM from address 0000h. (Note: many Z80 information pages wrote: Z80 registers erased at reset. It is not true, only PC,I,R erased.)
Nick chip halted while the reset signal active, but not reseted*! Will continue display the current LPT after the reset pulse. Because the little halt, you see screen jumping when pressing the reset.
* I don't know this is a bug or feature :ds_icon_cheesygrin:

When the EXOS ROM started then it is check the EXOS paging routines in the system segment (FFh), if these are broken the do cold reset, otherwise try a warm reset. No other data checked, this is why I suggest: if anything overwrited in the system segment, then zero fill it (least B210-B230h), then don't possible warm restarting with broken system data.

Offline Zozosoft

  • Global Moderator
  • EP addict
  • *
  • Posts: 14722
  • Country: hu
    • http://enterprise.iko.hu/
Ok, there is a modified sample for your memory map.
-0100-BFFFh for the program, it is checked for running non-VRAM. Program will exit if running in VRAM
-segment FCh,FDh,FEh are allocated for you, if not available then exit program.
-you can define FFh segment usage (VRAM4_SIZE), if possible then allocated for you, if not enough free then system segment zero filled (disable warm restart). About 6K are also free on well expanded configurations.
« Last Edit: 2016.July.15. 12:11:04 by Zozosoft »

Offline lgb

  • EP addict
  • *
  • Posts: 3563
  • Country: hu
  • æðsta yfirmaður
    • http://lgb.hu/
Reset button connected to the Dave RSTI input. The Dave generate short reset impulse to the system bus Reset line. Only one short impulse generated, don't depend of the pressing time of the reset button. This is important for the keep memory contents: on other systems where the reset button connected directly to the reset line, the Z80 halted until the button released, then no DRAM refresh!gest: if anything overwrited in the system segment, then zero fill it (least B210-B230h), then don't possible warm restarting with broken system data.

:) That's a nice explanation :) I only wrote my note, since I felt, some can think the RESET button on EP is not a hardware reset. EP's design is kinda interesting from this view point too, as far as I remember it was even mentioned that the original design team was unsure if a hardware reset feature could be used somehow not to "cold reset" the system but for using as a feature like this for "warm reset" as well (from the software point more). But the complexity of the reset logic in hardware level is especially done this way to avoid damage of the RAM content, etc, if I see well.

Offline Sdw

  • User
  • *
  • Posts: 50
Ok, there is a modified sample for your memory map.
-0100-BFFFh for the program, it is checked for running non-VRAM. Program will exit if running in VRAM
-segment FCh,FDh,FEh are allocated for you, if not available then exit program.
-you can define FFh segment usage (VRAM4_SIZE), if possible then allocated for you, if not enough free then system segment zero filled (disable warm restart). About 6K are also free on well expanded configurations.

Thank you very much! That seems to be exactly what I need, excellent!

Offline Sdw

  • User
  • *
  • Posts: 50
OH! And what is this little piece of magic:
Code: [Select]
                LD A,12 ;disable
                OUT (191),A ;memory wait states

I didn't have that one in my previous (self-written) framework. It seems to give quite a noticeable speedup, my routines dropped a good amount in used CPU-time!

Offline Zozosoft

  • Global Moderator
  • EP addict
  • *
  • Posts: 14722
  • Country: hu
    • http://enterprise.iko.hu/
OH! And what is this little piece of magic:
At default 1 wait state enabled at each M1 cycle, in non VRAM. I think because some very early machines used some slow DRAM/EPROM chips.
Many programs are disable the wait states, and now I also set the no waits as default in EXOS 2.4 .

Offline ergoGnomik

  • EP addict
  • *
  • Posts: 1291
  • Country: hu
  • Stray cat from Commodore alley
At default 1 wait state enabled at each M1 cycle, in non VRAM. I think because some very early machines used some slow DRAM/EPROM chips.
Many programs are disable the wait states, and now I also set the no waits as default in EXOS 2.4 .
Maybe this option is there to guarantee operation with the envisioned or planned 6MHz CPU option.

Offline Zozosoft

  • Global Moderator
  • EP addict
  • *
  • Posts: 14722
  • Country: hu
    • http://enterprise.iko.hu/
Maybe this option is there to guarantee operation with the envisioned or planned 6MHz CPU option.
6MHz machine need a different ROM image, use 6 (or 14) value for port 191, for set the right sound frequencies in Dave.
This is done for the Modell 911.