Welcome, Guest. Please login or register.

Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

Topics - elmer

Pages: [1]
Interface / Internal memory expansion plus USB
« on: 2021.March.02. 21:06:19 »
JLCPCB, the manufacturer that made my 512KB internal memory expansion board, has expanded the list of components that they offer, and can now also install USB connectors.

This has created the possibility of designing something that I would personally like to have ... an internal 1M byte memory expansion board, together with a USB port so that the Enterprise has a fast path to communicate with a PC, or perhaps a Raspberry Pi.

The FT245RL USB chip that I am thinking of using is very simple to interface with on the Enterprise side, and needs no complicated USB software to be written. All of the really difficult stuff is handled by the chip itself, and by the PC drivers that the manufacturer provides for free.

One of the friends who provided me advice on my previous board is already using the FT245RL in a new design that he is working on, and so I am lucky enough to have his experience to help me with an Enterprise board design.

The obvious use for the USB connection would be to quickly transfer files between the Enterprise and a PC, without the need to swap SD cards.

Although the FT245RL can transfer 1M bytes per second, experience on other 1980s computers has shown that we are more likely to get 50-100K bytes per second on the Enterprise.

The board layout (3" x 1.75") is nearly finished, and so I am thinking about how many to order.

If this works, and is affordable (approx $30 USD  or 10,000 HUF), would anyone be interested in a board like this?

One more thing ... since this uses a GAL for the memory decoding, I hope that it should coexist happily with the Symbiface3, EPNET and other existing Enterprise expansion boards.

I am currently planning to use segments C0h-FBh, and either B8h-BFh or 78h-7Fh.  Can anyone see any problems with that?


A JLCPCB, az 512 KB-os belső memória bővítőkártyámat gyártó gyártó kibővítette az általuk kínált alkatrészek listáját, és most USB-csatlakozókat is telepíthet.

Ez megteremtette a lehetőséget egy olyan dolog megtervezésére, amelyet személy szerint szeretnék ... egy belső 1 M bájtos memóriabővítő kártyát, egy USB-porttal együtt, hogy az Enterprise gyors utat tudjon elérni a PC-vel, esetleg egy Raspberry Pi-vel való kommunikációhoz. .

Az FT245RL USB chip, amire gondolok, nagyon egyszerűen kezelhető az Enterprise oldalon, és nem kell bonyolult USB szoftvert írni. Az összes nagyon nehéz dolgot maga a chip kezeli, és a PC-illesztőprogramok, amelyeket a gyártó ingyen biztosít.

Az egyik barát, aki tanácsot adott nekem az előző táblámon, már használja az FT245RL-t egy új dizájnban, amelyen dolgozik, és ezért szerencsés vagyok, hogy tapasztalataim segítenek az Enterprise fórum tervezésében.

Az USB-kapcsolat nyilvánvaló használata a fájlok gyors átvitele lenne az Enterprise és a PC között, az SD-kártyák cseréje nélkül.

Bár az FT245RL másodpercenként 1 millió bájtot képes átvinni, az 1980-as évek más számítógépein szerzett tapasztalatok azt mutatják, hogy nagyobb valószínűséggel kapunk 50-100 ezer bájtot másodpercenként az Enterprise-on.

A tábla elrendezése (3"x 1,75") majdnem kész, ezért azon gondolkodom, hogy hányat rendeljek.

Ha ez működik, és megfizethető (kb. 30 USD vagy 10 000 HUF), érdekelne valakit egy ilyen tábla?

Még egy dolog ... mivel ez GAL-t használ a memória dekódolásához, remélem, hogy boldogan együtt kell élnie a Symbiface3, az EPNET és más meglévő Enterprise bővítő táblákkal.

Jelenleg a C0h-FBh és a B8h-BFh vagy a 78h-7Fh szegmensek használatát tervezem. Láthat valaki ezzel problémát?

Programming / Improving IS-DOS
« on: 2021.February.10. 19:18:12 »
I think that I am finished with the "simple" upgrades to IS-DOS, and here is the latest alpha build for people to try. :mrgreen:

This does not add any new capabilities (MSX-DOS 2, ZCPR3, CP/M 3 etc) to IS-DOS, but it reorganizes the way that IS-DOS runs in memory so that it will be easier to make more changes in the future.

The big difference from IS-DOS 1.0, is that IS-DOS 1.1 now runs in a dedicated segment that it allocates for itself when it starts.

This means that the TPA size available for CP/M and IS-DOS applications has increased from 56KB to 63KB, which will now allow some CP/M programs such as the BDS C compiler to run.

The "fast" video driver has also been optimized to make it run at nearly (but not quite! ;-) ) double the speed, making CP/M (and IS-DOS) applications much nicer to use.

The tradeoff is that the "fast" video driver now only allows 2-palettes for text, but in return, it does not chop off the right hand pixel of the 'M' and 'W' characters, which looks nicer on the screen.

Although IS-DOS.SYS is now 1 disk sector shorter than before, using 13312 bytes instead of 13824 bytes, there is approximately 2KB of free space within the program to add new code/features. :cool:

EDIT 2021-02-14:

There is a bug in this 2021-02-10 version of IS-DOS 1.1-alpha, and register L has the incorrect value for MSX-DOS functions "Block Read" and "Get Time".

I suspect that these functions are not used by any of the applications that people run in IS-DOS, but this will be fixed in the next release of IS-DOS 1.1.-alpha. :oops:

Hardware / Like a Z180, but much better ... the Z280
« on: 2021.January.19. 23:00:44 »
I can see that there are a number of threads where people have talked about putting a Z180 into an Enterprise ... but how about the Z180's bigger and better (but less successful) cousin from 1987, the Z280?

It runs on 5V, it has a Z80-compatible bus mode, and it offers internal clock-doubling!  :shock:

I didn't think that there would be any of the chips still available, but apparently there are still a *few* for sale.

Programming / IS-DOS crash bug.
« on: 2021.January.04. 20:29:19 »
There is a crash bug in IS-DOS, probably introduced sometime between when the IS-DOS specification document was written, and the final IS-DOS version 1.0 was released.

The important difference is in the way that IS-DOS uses memory.

In the original specification, IS-DOS would always allocate 64KB of memory, and then its program code would stay in the same location all of the time, unless that location was changed with a "RELOCATE" command.

In the shipping version of IS-DOS, the program code moves itself automatically from the Page0 segment to a different segment, usually Page3, when a CP/M program is run ... and then it moves itself back to Page0 once the CP/M has finished.

This means that EXOS keeps more segments free for other things whenever IS-DOS doesn't actually need the memory in order to run a CP/M program.

The crash bug occurs whenever a CP/M file is loaded that is larger than the amount of memory that is available for a CP/M program (the TPA size).

IS-DOS detects this, and displays an "*** Insufficient memory" message ... but it does not move itself back to Page0, and it keeps all of its memory.

The next time that a CP/M program is run, IS-DOS get confused because it is not in Page0, and its memory allocation breaks, memory is leaked, and a crash occurs.

In practice, it is unlikely that anyone will ever encounter this problem in normal use, because it is something that only happens if memory is low (i.e. you run IS-DOS on an Enterprise with more that 64KB, but less than 112KB), or because you specifically try to run a program file that is larger than 51KB.

Now it isn't very difficult to patch IS-DOS to fix this bug, but I don't see it as being worthwhile unless someone is patching IS-DOS for other reasons.

The Enterprise's 40-column text video driver only allows two colour palette choices (0,1) or (2,3).

The Enterprise's 80-columm text video driver allows four colour palette choices (0,1), (2,3), (4,5), (6,7) ... but does so by enabling the Nick video setting that clips off the right hand side of text characters.

This works, but it looks really ugly, and from my personal point of view, it makes the Enterprise look really bad in comparison to the Amstrad CPC and the BBC Micro! :(

From what I can see, programs like EPDOS, HEASS, FENAS, etc implement their own 80-column text ouput routines so that they can avoid this and use the full 7-pixel width, even though that limits them to two colour palettes, the same as 40-column text.

Does anyone know of any Enterprise programs that use the 3rd or 4th colour palettes in 80-column text mode?

Can anyone think of a reason why I should not just patch EXOS to use the full 7-pixel width and limit 80-column text to two palettes?

From what I can see, all of the Intelligent Software languages only use two palettes anyway, because they need to work in both 40-column and 80-column text modes!

Programming / HEASS and FENAS manuals?
« on: 2020.November.29. 18:18:53 »
Are there any downloadable or online manuals for HEASS and FENAS (and maybe ASMON)?

Are HEASS/FENAS/ASMON only available in ROM versions, or are there versions of them as extensions that can be loaded from SD card?

Thanks! :)

Programming / Changing the EXOS font
« on: 2020.November.21. 19:59:02 »
One of the things that I always found interesting about the 8-bit era of computers is the difference in every machine's system font that either helped, or hurt, the readability of the text on the screen.

Because nearly all computers used an 8-pixel high font, each computer's designers had to choose whether to make their upper-case characters either 6 or 7 pixels high, depending upon whether they wanted the character shapes to look nicer (by using 7-pixel height), or whether they wanted to avoid the descenders of the "gpqy" characters hitting the tops of many upper-case characters on the line below (by using 6-pixel height).

One of the unusual, and really great, things about the Enterprise is that it has a 9-pixel high system font that could have allowed it to use both the nicer 7-pixel height for upper-case characters, and to still avoid the unpleasant look of having descenders hit the top of the upper-case characters on the line below.

Unfortunately, whoever it was at Intelligent Software that designed the font, didn't actually do that ... which is something that I always found annoying when I was using my Enterprise back in the 1980s.

Now that I am using EXOS 2.4, and can program my own EXOS EPROM, I decided to fix that, and to also modify a few other characters to make them look a little nicer (in my own personal opinion).

Long time Enterprise programmers will probably already know that the system font is stored compressed in the EXOS ROM, so I had to figure out how this worked, and then figure out how to patch the code to alter the compression a bit, and to then compress the new font into the same 630 byte memory space that the old font fits in ($E5D2-$E847 in EXOS 2.1).

Anyway, here is the result, showing the original EXOS 2.1 font on the left, and my updated font on the right.  The changes are easiest to see on the Hungarian version of Zozo's RAM test, but the Spanish and German versions also look better (to me).


Since "beauty is in the eye of the beholder", I understand that few people here may be interested in using this themselves, but if anyone is curious, I can post the source code for font-decoding patch, and for the utility that I wrote (on the PC) to apply the patch (and the font) to Zozo's EXOS 2.4 ROMs.

For editing bitmapped-fonts, I recommend that folks use Fony, because it is easy to use, and can export the font as raw binary data.

Pages: [1]