flashjazzcat

Pah! Buy three or more if possible. Even if you don't need more than one, you're supporting the creators and encouraging them to invent new stuff.

For info: the PBI driver consumes no system RAM at all. PBI devices usually include their own ROM and RAM which is typically mapped underneath the FP ROM ($D800-$DFFF) or in the $D1xx region.

This one is different.

Does it do this immediately on a cold power up (after being turned off for hours), or only when power cycling? If the latter, then the symptom can indicate that the DRAMs are taking a while to lose their contents. This causes the OS to think a warm reset has been performed, and problems ensue. Waiting a few seconds more after powering off before powering on again usually fixes this.

Just tested here using UFLASH 3.10 and the 192K SDX 449e ROM and it worked perfectly. So it appears you experienced a random hardware glitch rather than an endemic compatibility issue. No hardware tests are performed while reading the ROM into extended memory, and if you saw such a message appearing while the program is merely reading chunks of the file into one memory bank after another, I'm afraid we are not dealing with deterministic hardware behaviour.

In what sense does it not recognize it? Make sure you pick the correct sized SDX ROM; there are three offered in the DLT archive: 192K, 256K and 320K. UFLASH will accept only the one which matches the size you specified in 'SDX ROM Size' on the Options menu: Without further details of the problem, I can only assume you chose a ROM which didn't match the specified SDX size. There is no reason why it would not work, otherwise. The SDX ROM on the 449e flasher ATR is 256K in size, and it's highly likely that you have the size set to 192K or 320K.

Unless you have U1MB, CONFIG.SYS cannot be read from the HDD because it's CONFIG.SYS on the CAR: device (in ROM) which loads the driver for the HDD. Chicken and egg situation.

On the face of it, having a couple of discreet device handlers isn't a bad idea. If device #1 is reserved for the PBI HDD and SIO, device #2 could be repurposed to suit the needs of the user (FujiNet, etc). Writing the PBI BIOS and later the loader was definitely an education in writing banked ROMs/carts. The LJSR macro encodes the destination bank and address in 2 bytes of in-line data following the call to the LJSR function (this is possible thanks to the fact only 11 bits are required for the target address; the bank number is packed into the high 5 bits.

I'm expecting much more PBI ROM and RAM space for future expansion, but there are not currently any plans to implement multiple discreet PBI device handlers on the same hardware. The 2KB ROM window is hardly a limitation at all. The existing U1MB PBI BIOS ROM is 8K in size, but split across 4x 2KB banks. Inter-bank JSRs are accomplished by macros which call the entry code which is located at the same location at the top of every 2KB bank (where the exit wrapper is also situated). Overheads are small, although one obviously seeks to avoid inter-bank calls in speed crtitical sections. But you can scale this up as large as you need to go without too much trouble. Likewise the SIDE3 loader does a lot of bank switching (although the banks are 8KB in size there). The OSS languages (BASIC XL, Action!, etc) are other good examples of very efficient, tightly coded bank-switched ROMs (they have one static 4K ROM bank and a 4K banked window).

Not to mention those without a hard drive who enjoy the U1MB's built-in OS agnostic high-speed SIO driver which is capable of divisor 0 transfers. In fact, the PBI/NewDevice API is a perfect way to extend the functionality of the OS without having to write a new operating system at all. All the U1MB PBI BIOS is essentially doing is incorporating driver code into the OS without changing the underlying OS. If one is going to rely on third-party hardware anyway (U1MB or some new variant thereof) in order to have a 32K bank switched OS presumably packed with driver code, you might as well just build additional PBI device handlers into it (the stock OS supports up to eight) to accomplish what you want. PBI handlers can even register themselves as HATABS device drivers, so you could have - say - a PBI 80 column display driver which didn't require the loading of any drivers at all.

Probably over a thousand U1MB users, not to mention IDE Plus, MIO, etc. What Apple would call 'a very small percentage'.

Yeah: I made four posts, in whcih I speculated about putting the existing GUI on top of Nitros-9 and downloaded the source (which I probably looked at once and then forgot about). Back in 2012 my GUI had no multi-tasking capabilities whatsoever which is probably why the idea seemed superficially appealing. I think I wrote the mutli-tasking kernel during a two week coding binge in 2014. I would like a bottle of whatever I was on in those days.

My memory can be vague too, so I'm not saying it didn't happen. The primary influence on the redesign on the window manager and the main 'consultant' when it came to the multi-tasking micro-kernel, however, was Jorn Mika (@Prodatron); I don't really know much about Liber809, but I was under the impression it didn't have a Graphical UI. Perhaps there was some flow of information in the other direction... I dunno. I was just curious to look back on any such discussions.

Yes indeed. Also a distraction-free experience. From what I can gather, the optimial retro word processing experience appears to be ProText on the Atari ST. That word processor long fascinated me and one day - when I get time - I will make a work/lookalike for the A8 (80 columns are a must here).

I know one forum member who uses TLW to prepare printed material for his teaching job, and another who uses it to edit documentation and source code for a publicly released project. It's nice to hear you consider the software impressive, but TLW is not really intended as a 'jackhammer'. I would say if it were able to edit 1MB text files contiguously, perform mail merge on vast data sets, possessed a WYSIWYG display and comprised 100K of code, it might be a jackhammer in terms of word processing. As it stands, it's perhaps overkill for some light text editing jobs (ED, EDX, XEDIT, etc, may be more appropriate). But for 'word processing', something with multiple buffers, fast insertion, optional 80 column display and a powerful disk menu is pretty much the bare minimum, IMO (I say this after using AtariWriter and TextPro for actual writing in the 90s).

I'd very much like to read that conversation myself.

Very well. I am preparing updates to the manual now; after that, I will start putting the distribution together.

LOL... well, I guess we discovered that there are people who INSIST on using mirrored locations. Yes, it was extremely well designed by the original author, and the current developers have likewise done a great job of making intelligent and well thought-out improvements.

Unfortunately not. Until the config is locked, the BIOS setup menu ROM is fixed in the OS ROM address space. Locking the config is essential anyway, since bad things could otherwise happen because of accidental writes to the control registers in the PIA address range (the registers disappear when once the configuration is locked, to become visible again when RST is pulled low). The address space contention between code and data in extended banks can be a big problem, for sure. That's the main reason I decided to put my GOS on a bank switched cartridge. Of course this assumes you want or need to use extended RAM banks for data too, which may not be the case. Careful placement of code and data can still overcome these limitations, though (see SDX drivers which place the majority of their code in extended RAM, but are still able to work with data in the extended RAM banking window).

I once had a CPLD on an U1MB or Incognito (I forget which) which suffered bit rot that resulted in half the 1MB extended RAM being a mirror of the other half and a CPLD re-program fixed it, so strange things can happen.

You could have a 1MB or larger language on ROM; just use a banked cartridge.

My first thought it that you cannot programatically switch between the four OS ROM banks on the U1MB unless you are the setup menu. Only the reset line being pulled low allows the configuration to be unlocked, which is a pre-requisite for switching ROM banks. There's no real reason you couldn't use extended RAM banks for a similar purpose, though; SDX already greatly extends the core functionality of the machine via drivers which may reside almost wholly in extended RAM banks.

I decided to chronicle my RetroBriting experiments with UV 'grow lights':

It's a pre-emptively multitasking graphical OS capable of running sixteen concurrent processes. Not really a compelling argument for 1MB until it's finished and usable, but it's built into almost every U1MB board.

I don't think I'm missing the point at all; I'm directly addressing the assertion that 'a Word Processor on an 8-Bit system can not be considered a "killer app"'. I happen to disagree, and do so without claiming that the example presented (TLW) is said 'killer app'. If he's interested soley in games, why does he rephrase the question in post #4 as 'What is the "killer app" for 256K, 320K, or 1MB?' One can hardly blame anyone for suggesting a word processor or spreadsheet in response to that.