Welcome!
Wow, nice demos! And so many different hardware, even one of my favourites: C64DTV
Yes, I read that there were such things available, which is cool! However, with the price of the Enterprise128 being quite high, and I guess these solutions being quite expensive and rare, I have to stick with loading from tape-port via my PC for now.
I think the "new standard" nowadays maybe the SD card solution (it sticks into the cartridge port where IS-BASIC resides normally, but no need to worry, as the SD card cartridge also contains flash, so it can even act as the old function of the cartridge port we can say, and a bonus, that you can modify the content), which is quite modern, but fast and big enough. And not so much expensive, well, I have no exact idea, but about 30 EUR or such, maybe? Others here may know this better
I think, the key factor of EP besides the hardware is its OS. Well, yes OS, especially compared to other 8 bit machines it feels "odd" maybe at the first sight how complex it is, with even "device drivers" etc. But it's also the solution that a brand new mass storage device (like the SD card cartridge) does not need modification of the original ROMs and usually it doesn't cause compatibility problems with software etc, which is often not so easy topic on other 8 bit systems. Just check the situation out with eg IDEDOS on C64 ... (don't get me wrong, C64 is still my favourite as being the first computer of mine).
OK, so if I understand correctly, I should zero-fill the 0xc000-0xffff bank, directly when I enter my program, that is, I shouldn't switch anything specific into it, but just assume that what is at those addresses are what should be zerofilled?
Be careful with the notions, "0xc000-0xffff bank" (actually "page 3") can be anything, it depends what of the Enterprise 4Mbyte address space is "mapped" (which 16K segment, for page 3 it's I/O port 0xB3) to that Z80 page. I guess you mean here, that segment $FF (the last 16K of VRAM, also called "system segment" as the OS - EXOS - stores its things there) is mapped to page 3, right?
Having a "complex" and "dynamic" OS (ie it can have different EXOS_ROMs etc) also mean that it's not so much possible to tell the exact memory addresses of certain things. But for sure, you can still drive the computer "directly" when you may not need EXOS etc at all, overwriting stuffs, if you want. However keep in mind, that you may have problems if you need to load extra stuffs then (next part of demo, etc) if you trashed the OS out ... Surely you can instruct the hardware directly for load, but this is the situation where you meet the problem that many different storage techniques are/were used, which is transparent through the EXOS, but of course it is not, if you do it yourself.
(VRAM C000-FFFF) into the top bank, fill it with LPT data, and everything is ready?
Or do the VRAM page with gfx data also need to be banked in and visible to the CPU for the LPT to be able to display it?
No, even no VRAM at all needed to be banked in for the Nick (it's true for the LPT as well, or for everything which is read by Nick chip itself). The described page/segment and "mapping" method is _ONLY_ for the CPU strictly. Nick as the video chip *always* sees the 64K VRAM (in case of EP64 this is the only RAM in the system without expansion, that's why EP64 is slower than an EP128 which also has an internal memory expansion panel installed for additional 64K which is not VRAM thus faster). And it always sees linearly. CPU address "mapping" does not mean anything for the Nick, it also wants "Nick addresses". Eg, if you send 0xFC to port 0xB3, then for the Z80, you can see the first byte of VRAM at address 0xC000, but for the Nick it's the address 0. Actually, I think it's cool, you can have even *no* VRAM segment is paged in at all, Nick will still display its stuffs of course! And it's also true, that the VRAM can be seen by the CPU at segments 0xFC, 0xFD, 0xFE and 0xFF. The non-VRAM RAM areas (not so much in Ep64 without expansion of course) can have different layout, even at non-continuous segments (!) that's why you should allocate memory via EXOS, as the OS knows (it scans at the "boot" time) where usable RAM segments are, it's depend on memory expansion solutions, etc. But for VRAM, you can know where it is, even without EXOS (it's another thing, that it's nice to use EXOS anyway if you plan to have "EXOS compatible" software at least - but to be honest: for a really "serious" demo I can imagine that you need every bytes of the RAM and it won't be EXOS compatible, so you need cold reset / etc solution then).
Finally - a question of IRQs. I want to set up a VBL-IRQ that is called once per frame. Does that mean that I should use the LPT-IRQ-bit in one of the rows, or is there a better way?
What is VBL? Vertical Blanking maybe? You can have set IRQ for any LPB of the LPT even for more one, just one thing should be known: you can't have IRQ for two (or more) continuous LPBs as it wouldn't produce an "edge" (IRQ itself is level triggered on the Z80, but I mean at Dave/Nick level) of the signal between the two LPBs. Also it seems (and "AFAIK") IRQ is generated actually at the _end_ of the LPB which was configured with VINT bit for video interrupt.
Sorry for all the questions!
Why?
It's always cool to talk about things like this, and helping each other!
I have to say that so far I really like the Enterprise128, the LPT system is really cool, with the possibility to change how wide the screen is, and the different gfx/characters modes are also really nice.
Coming from C64 primarily, I do miss the sprites though!
I agree. Nick is quite smart stuff, and LPT allows nice tricks done by the hardware then without any CPU usage (as with doing raster interrupts on C64 to modify settings, etc). You can even try things, to show the same content at two (or more) places throughout the screen even with tricky LPT to do one instance as "upside-down" or with different palette - or for example animations played by hardware (surely the size of VRAM is a limiting factor here) etc. And it's kinda cool that you have 256 colours to choose from, as well. But well, yes, sprites are missing, sometimes badly missing ... Nick has "EXTCOL" inputs (external colour) so there can be image data "fed" digitally, AFAIK "sprite module" was even planned as an add-on with attached onto the EXTCOL inputs of the Nick chip.
Yeah, I have dabbled in several different CPUs.
My main background is C64, so 6502-assembler is the one I know best. I know Z80 fairly well, and then there are others (68000, 6809 etc.) that I can code in a bit, but not very good at all!
This was about my situation as well.