New GUI for the Atari 8-bit

[+MrFish]

Oh, OK, you are already using a conversion program.

 

The fonts from Dpaint IV, AmigaTerm, TextCraft, Prowrite, Excellence, and one called XEN, all come to mind, rather quickly.

All of the non-commercial Amiga fonts can be found on Aminet, right here:

http://aminet.net/search?query=font&start=0

 

As far as the commercial ones go, I know of no one specific font archive, however practically everything ever released is available if you go looking for "amiga collections".

 

That's the same archive I used to do a bunch of conversions from back in 2012, and frankly, as I mentioned already, I wasn't impressed at all. IIRC, 128 character sets, and mediocre quality. I may have just made some bad picks in the ones I chose to convert. But unless you can point me to some particular ones that are worth spending time on, I don't plan on sifting through the collection again, as I know what I have far exceeds what I've seen from this collection so far -- I recall converting 20 - 25 of them. Mind you I'm comparing this to a very nice hand picked collection I've culled from the old 68K Mac days. We're really in good shape already. So I need something a little more specific in order to merit spending any amount time.

 

 

One language that you may want to investigate for creating your own editing & conversion tools is TCL/TK. Very easy to learn, & your source can be used on Mac, Win, UNIX, Linux without modification. It is very easy to create GUI elements, and a whole application can be put together really quickly.

 

For example, you could make a program that loaded two fonts in, with different formats, displayed them, and let you edit each character, on it's own canvas. It's a super-simple matter to work with clickable lists, file requesters, any gui element. You could also assign pullldown items, or buttons to do batch converts on directories of fonts, or do conversions from your current spec 1 fonts to the proposed spec 2 fonts, etc. Other than that, it also allows you to directly integrate other languages, right from the language, itself.

 

A lot of people have forgotten about TCL/TK, but really, it is quite an awesome language (as is it's variant, "Expect"). You can get it for free through ActiveState, here:

http://www.activestate.com/activetcl

 

You'll be amazed at how fast you can take a small algorithm, and turn it into a Windowed application. Great stuff for quickly turning an idea into a usable windowed application. It pretty much lets you be as creative as you could have been with BASIC, back in the day.

 

Hope that helps you. You may be able to take your code, port it to TCL/TK, and have all of your tools available, all in one place, to save yourself some time.

 

I'll take a look at it. Thanks for the information.

[+MrFish]

IIRC, 128 character sets, and mediocre quality.

 

My bad. They have more than 128 characters per set. I just popped one open again.

[fibrewire]

Now that the GUI shows how fast the small font renders, I imagine a normal size font is rendered even faster in a window. Will the GUI be able to quickly render a different font in each window easily, or multiple fonts in a single window?

[flashjazzcat]

Yes.

[fibrewire]

Bumping this thread so it doesn't get buried too deep in the AtariAge forum

[Prodatron]

Always hungry for news

[flashjazzcat]

Nothing to report at the moment, I'm afraid. Still backed up with slightly more mundane tasks. However the end is in sight, and at that point I will continue with getting the GUI onto ROM, which absolutely has to be the priority job. Hopefully compiler uncertainties (re: relocatable file format) will resolve themselves by the time that's done...

[flashjazzcat]

Big whoop: slightly updated web page.

 

http://atari8.co.uk/gui/

 

Fortunately, the fact I was focused enough to do this is encouraging and significant in itself.

[Prodatron]

Wow, that looks much more professional! Did you change the whole CMS? Was interesting to read the new text, and thanks for mentioning

[flashjazzcat]

Wow, that looks much more professional! Did you change the whole CMS? Was interesting to read the new text, and thanks for mentioning

 

Thanks! It's actually not a CMS - just CSS themed HTML. I figured there weren't enough regular content changes to warrant a CMS.

 

The mentions are well-deserved.

[+MrFish]

Big whoop: slightly updated web page.

 

http://atari8.co.uk/gui/

 

Fortunately, the fact I was focused enough to do this is encouraging and significant in itself.

 

It looks like you've officially made the decision that FAT will be the base filesystem. As mentioned before, I'm all for that. Does this also mean that long filenames will be supported, or will we stick with 8-3?

[flashjazzcat]

It looks like you've officially made the decision that FAT will be the base filesystem. As mentioned before, I'm all for that. Does this also mean that long filenames will be supported, or will we stick with 8-3?

Well, that makes three big hitters who think it's a good idea.

 

Whether we might use LFN is an interesting question, and I'm instinctively inclined to say no, if only because of the difficulties it introduces in moving data between one file system and another on the Atari (say, if you wanted to copy something from a FAT volume to an SpartaDOS file system volume). There's also the the MS LFN licensing issue, which I actually think is probably a non-issue for a project this size, but nevertheless something to be aware of. The third "against" is probably the corresponding increase in the amount of space required to adequately display long filenames on the screen. And yet a fourth is probably the processing and storage overheads involved in encoding and retrieving long filenames.

 

So, I guess we stick with 8.3.

Edited January 28, 2014 by flashjazzcat

[+MrFish]

Well, that makes three big hitters who think it's a good idea.

 

Whether we might use LFN is an interesting question, and I'm instinctively inclined to say no, if only because of the difficulties it introduces in moving data between one file system and another on the Atari (say, if you wanted to copy something from a FAT volume to an SpartaDOS file system volume). There's also the the MS LFN licensing issue, which I actually think is probably a non-issue for a project this size, but nevertheless something to be aware of. The third "against" is probably the corresponding increase in the amount of space required to adequately display long filenames on the screen. And yet a fourth is probably the processing and storage overheads involved in encoding and retrieving long filenames.

 

So, I guess we stick with 8.3.

 

I assumed that we'd stick to 8-3, but one never knows what you may have up your sleeve. I'm perfectly happy to have FAT alone, but in answer to your cons: I move data between filesystems all the time, and I always assumed the difficulties were on the user. Screw MicroSoft's license. I think space-wise things could be left as they are, using stunted-names that expand via tool-tip like mouse-hovers. Either that or carefully named 8-8 filenames (burden on the user) with hidden extensions displayed on mouse-hovers. I don't think storage overheads are a problem these days. I'll agree on the processing though.

Edited January 28, 2014 by MrFish

[+Ripdubski]

Nothing at all wrong with 8.3. Nice site update!

Edited January 28, 2014 by Ripdubski

[+MrFish]

Nothing at all wrong with 8.3. Nice site update!

 

I agree. In fact I'm not even saying that I'd like to see long-filenames in the GUI, even though there are a lot of benefits to having them. From an aesthetic view-point, which is which my arena, 8-3 filenames are certainly more manageable, especially given our screen resolution. So, if I were to vote, I'd most likely go with 8-3. I was simply answering Jon's con list, for the sake of it.

[+Ripdubski]

 

I agree. In fact I'm not even saying that I'd like to see long-filenames in the GUI, even though there are a lot of benefits to having them. From an aesthetic view-point, which is which my arena, 8-3 filenames are certainly more manageable, especially given our screen resolution. So, if I were to vote, I'd most likely go with 8-3. I was simply answering Jon's con list, for the sake of it.

Understood. I was not debating, just agreeing that 8.3 is OK.

[+MrFish]

Understood. I was not debating, just agreeing that 8.3 is OK.

 

Hey, no problem. I posted the message about FAT in part to stir up some opinions.

[fibrewire]

I agree on 8.3!

[+Stephen]

Another vote on the 8.3

[flashjazzcat]

I'm perfectly happy to have FAT alone, but in answer to your cons: I move data between filesystems all the time, and I always assumed the difficulties were on the user. Screw MicroSoft's license. I think space-wise things could be left as they are, using stunted-names that expand via tool-tip like mouse-hovers. Either that or carefully named 8-8 filenames (burden on the user) with hidden extensions displayed on mouse-hovers. I don't think storage overheads are a problem these days. I'll agree on the processing though.

Judging by recent experience, putting even the mildest difficulties on the user can provoke bitter complaints from the outset. But in any case, some difficulty would be on me, since I'd have to figure out a way to unambiguously encode a long filename into an 8.3 SDFS (for example) filename when copying between two volumes.

 

Tooltips are a perfectly valid way of compressing the long names, yes. But obviously text boxes in file selectors would have to open up a bit, alert boxes showing whole paths would be bigger, etc. It has a slight but discernible knock-on effect on the whole interface, but nothing unmanageable, using the ideas you suggest.

 

Storage - well, it depends whether we're talking about disk or RAM capacity. Sure we have 1MB upgrades today, but we're hoping to make something that will run on (minimally) a 64KB XL/XE. If a file selector needs to retrieve, sort, and display (say) a maximum of 256 filenames per folder, then a packed directory of 8.3 names (plus time/date/size/attribute/cluster information) at 32 bytes per entry will consume 8KB of RAM. Long filenames would need to be decoded on the fly when reading the directory, which isn't a major issue in terms of processing, and at least gets the file list down to manageable proportions. But still, 256 filenames of - say - an average length of only 40 characters would consume 10,240 bytes of RAM for the filenames (assuming they're reduced from UCS-2 encoding to 8-bit codes), and around 5KB for the attributes, cluster number, etc, making a total of nearly 16KB. That's a whole bank of extended RAM just to store the sorted directory.

 

Then there's the question of directory allocation and seeking. Using LFN, directory size (I'd estimate) is typically quadrupled, since we have the short name, plus extra directory slots (of 32 bytes each), holding at most 13 characters of the long filename per slot. So a long filename of 29 bytes consumes four slots: three for the LFN and one for the alias. When searching the directory, this will make a big difference, especially on a serial device. On hard disks, it's not such a massive issue, since we can typically read at 60-70KB/s, and if we spend half the cycles (say) actually parsing the directory, we could still get through 1,000 entries a second, or 256 LFNs consuming 4 directory slots each. The picture changes dramatically with a serial device, of course, but with reasonably sized directories, not impossible.

 

We also need to allocate new slots in the directory, and the same magnitude of overhead applies here when using LFN.

 

So, as nice as it would be to have long filename support, it would probably be best implemented via a completely new filesystem, and this would do away with the compatibility offered by FAT, while introducing yet another filesystem that we could probably do without.

 

So, another +1 for 8.3.

 

Regarding FAT itself, this - like LFN - is amply documented elsewhere. Suffice it to say that FAT sizes on modestly sized partitions remain reasonably small (in FAT16), so that even the overhead of having to recalculate the free sector count every time the volume is mounted isn't such a tremendous problem, at least with hard disks. The FAT is only 16 sectors long on a 32MB FAT16 volume if 8KB clusters are employed. With FAT32, we enjoy a running free sector count in the boot sector, but a FAT doubles in size for the same cluster geometry. As the volume sizes increase, we face the difficult choice of using smaller clusters to minimize wastage, thus making the FAT itself larger and more time consuming to seek, or using larger clusters, a smaller FAT, and thus decreasing sector allocation overheads. I'm sure this will be a lot of fun to work out.

Edited January 29, 2014 by flashjazzcat

[+MrFish]

Judging by recent experience, putting even the mildest difficulties on the user can provoke bitter complaints from the outset. But in any case, some difficulty would be on me, since I'd have to figure out a way to unambiguously encode a long filename into an 8.3 SDFS (for example) filename when copying between two volumes.

 

Tooltips are a perfectly valid way of compressing the long names, yes. But obviously text boxes in file selectors would have to open up a bit, alert boxes showing whole paths would be bigger, etc. It has a slight but discernible knock-on effect on the whole interface, but nothing unmanageable, using the ideas you suggest.

 

Storage - well, it depends whether we're talking about disk or RAM capacity. Sure we have 1MB upgrades today, but we're hoping to make something that will run on (minimally) a 64KB XL/XE. If a file selector needs to retrieve, sort, and display (say) a maximum of 256 filenames per folder, then a packed directory of 8.3 names (plus time/date/size/attribute/cluster information) at 32 bytes per entry will consume 8KB of RAM. Long filenames would need to be decoded on the fly when reading the directory, which isn't a major issue in terms of processing, and at least gets the file list down to manageable proportions. But still, 256 filenames of - say - an average length of only 40 characters would consume 10,240 bytes of RAM for the filenames (assuming they're reduced from UCS-2 encoding to 8-bit codes), and around 5KB for the attributes, cluster number, etc, making a total of nearly 16KB. That's a whole bank of extended RAM just to store the sorted directory.

 

Then there's the question of directory allocation and seeking. Using LFN, directory size (I'd estimate) is typically quadrupled, since we have the short name, plus extra directory slots (of 32 bytes each), holding at most 13 characters of the long filename per slot. So a long filename of 29 bytes consumes four slots: three for the LFN and one for the alias. When searching the directory, this will make a big difference, especially on a serial device. On hard disks, it's not such a massive issue, since we can typically read at 60-70KB/s, and if we spend half the cycles (say) actually parsing the directory, we could still get through 1,000 entries a second, or 256 LFNs consuming 4 directory slots each. The picture changes dramatically with a serial device, of course, but with reasonably sized directories, not impossible.

 

We also need to allocate new slots in the directory, and the same magnitude of overhead applies here when using LFN.

 

So, as nice as it would be to have long filename support, it would probably be best implemented via a completely new filesystem, and this would do away with the compatibility offered by FAT, while introducing yet another filesystem that we could probably do without.

 

So, another +1 for 8.3.

 

Regarding FAT itself, this - like LFN - is amply documented elsewhere. Suffice it to say that FAT sizes on modestly sized partitions remain reasonably small (in FAT16), so that even the overhead of having to recalculate the free sector count every time the volume is mounted isn't such a tremendous problem, at least with hard disks. The FAT is only 16 sectors long on a 32MB FAT16 volume if 8KB clusters are employed. With FAT32, we enjoy a running free sector count in the boot sector, but a FAT doubles in size for the same cluster geometry. As the volume sizes increase, we face the difficult choice of using smaller clusters to minimize wastage, thus making the FAT itself larger and more time consuming to seek, or using larger clusters, a smaller FAT, and thus decreasing sector allocation overheads. I'm sure this will be a lot of fun to work out.

 

I meant disk drive storage space. I can see the RAM needs easily being a burden.

 

I'm perfectly happy with 8-3. We have enough considerations fitting 8-3 filenames on screen with all the other elements competing for space...

[Chilly Willy]

I have two 65XE consoles, an 800XL console, and two 400 consoles. So requiring more than 64KB of ram would prevent me from using it until I got some kind of ram expansion. I also have the 1Mbit AtariMax flash cart, so I could use a version that required a cart like that (lots of flash banks).

 

It might be time to start looking at what systems would be best targeted to reach the most people.

[flashjazzcat]

I meant disk drive storage space. I can see the RAM needs easily being a burden.

 

I'm perfectly happy with 8-3. We have enough considerations fitting 8-3 filenames on screen with all the other elements competing for space...

Understood Paul. As you say, posing the question provided a good opportunity to air some of the technicalities.

 

I have two 65XE consoles, an 800XL console, and two 400 consoles. So requiring more than 64KB of ram would prevent me from using it until I got some kind of ram expansion. I also have the 1Mbit AtariMax flash cart, so I could use a version that required a cart like that (lots of flash banks).

 

It might be time to start looking at what systems would be best targeted to reach the most people.

I'd hoped the revised web page would remove some doubt on the subject of hardware requirements, but in fact it's probably not as unambiguous as I'd supposed. The fact is, owners of unexpanded 64KB XL/XE compatible machines who are interested in using the GUI/GOS will have to count themselves very fortunate if the system runs on their hardware. 64KB support is only being entertained at this stage because the a significant re-write over a year ago moved many of the internal structures out of extended RAM (although all but those applications which fit in the base bank at $4000-$7FFF will still run in extended banks, which more or less rules out running more than one application - or indeed keeping the desktop running in the background - if you only have 64KB). Nevertheless, 64KB remains in the bullet list for now, but I don't know if it will remain there.

 

Base configurations/software I have already decided will not be necessary (despite it being suggested I require them):

• 65c816 accelerator
• WDC 65c816 CPU (i.e. coding the entire system in 65c816 in order to make use of linear RAM, movable stacks, page zero, etc).
• VBXE
• SpartaDOS X
• IDE hard disk

It's obvious to me that making an absolute requirement of any or all of the above would narrow the potential user base somewhat, as well as inviting criticism along the lines of "well, of course it works: it's using a 14MHz CPU, a blitted 320x200x256 display, and 1MB of linear RAM". That's not to say there will be anything stopping anyone from running the 6502 code at 14MHz on a 65c816 CPU (cycle counting having now been dispensed with), or on a VBXE equipped machine (which I do myself 100 per cent of the time).

 

Now, even if the GUI does manage to run in 64KB of RAM (by cramming those parts of itself which don't run directly from ROM into the Shadow RAM and low memory), I would venture that the first thing the owner of a 64KB machine will then do (assuming the end product is any good and holds his interest) on realizing he can only run one application at a time, and that with severe limitations, will be to go out and by a plug-in or internal memory expansion, and probably a hard disk. Following that logic, it would have been pretty reasonable to at least require 128KB as the bare minimum. But I suppose 64KB support of some kind might at least tempt some people in who were otherwise sitting on the fence.

 

Another thing the website perhaps doesn't make clear is that the GUI will be delivered via banked ROM, and the AtariMax 1Mbit cartridge is ideal for this purpose, as are many other flash cartridges, and of course the 64KB of unused space in Ultimate 1MB and Incognito, once the base bank of that space is made bootable. Moreover, Steve Tucker was kind enough to design a RAM cart (with a flexible ROM/RAM banking scheme), which unfortunately remains un-utilised to this day, as I figure out whether it's feasible to bank the RAM in 8KB chunks alongside the ROM, and whether there is even room to do so alongside the 8KB frame buffer.

 

The above discussion of the memory requirements for a simple 8.3 DOS file selector offers a glimpse into how tight memory would be on an unexpanded machine. The system font is 1.2KB in size, and this is without additional tables and extra characters which it will eventually contain. The icon label font consumes another 1KB, and will get bigger. These fonts can be paged out to disk, but this will not result in a pleasant experience on a 64KB machine with a serial disk drive. We also require a number of 512 byte DOS buffers... the list goes on.

 

So: that's about as specific as I can be right now. Hope that helps.

 

PS: Stock 400, 800, 600XL - forget it.

Edited January 29, 2014 by flashjazzcat

[+CharlieChaplin]

Big joke:

 

"PS: Stock 400, 800, 600XL - forget it. :)"

 

Bigger joke:

Make the GUI work on the VCS2600 RAM then ! (Thats 128 Bytes) ;-)

 

But enough of joking, continue with your great work !

-Andreas Koch.

Edited January 29, 2014 by CharlieChaplin

[The Usotsuki]

Well, GEM did just fine with 8.3 filenames...