mizapf
-
Content Count
5,351 -
Joined
-
Last visited
-
Days Won
3
Posts posted by mizapf
-
-
I've tried compiling MESS but without success.
Please contact me, it should be possible to get MESS to compile without problems.
-
DSK files are disk images, i.e. their contents, sector by sector. I call this a sector dump image (aka v9t9 format), opposed to a track dump image as used in PC99. They allow for all operations that you know from the real media handling. They have a constant size because they always contain all sectors / tracks.
Archive files also contain files, but they are limited compared to a disk image. They consist first of a list of file headers, just like the ones from TIFILES format but shorter, then starting from the next sector, all sectors of the first file, of the second, the third etc. So if you want to find a file in an archive you have to skip over the earlier files. This also means that you cannot change files in an archive if this changes its sector count. Archive files can be compressed using LZW compression. Unfortunately, you cannot pack directories into an archive, but you can certainly store archives in an archive.
I had to learn all that stuff to include it in TIImageTool. As I wanted to create an illusion of a directory in which you can put files, rename them, delete, or create new ones, it always recreates the archive on the fly when you change something (even recursively, could not resist :-) ).
-
1
-
-
OK, I've got the information. Indeed, the schematics do not show any connections to the CRUIN / CRUCLK pins on the cartridge port.
-
Slightly related to that: Are there any specific, functional hardware changes in the QI consoles (apart from a new PCB layout)? I remember reading somewhere that CRU lines are not routed to the cartridge port anymore.
-
OK, I think I have fixed the problem by updating the code of hsgpl.c. I do not have a simple way to check whether this works as expected, however.
You can pull the update from the subversion repository and rebuild MESS on your own, or you can wait until the next update is published.
Michael
-
The HSGPL manual explains CALL SCON this way:
"Turns on the SuperCart emulation. Unlike the normal SuperCart, the 6000 ROM area is twice available, i.e. on all even and odd GROM banks there is the same ROM area, respectively. When the 6000 area is needed, modules on other banks cannot be used as long as the SuperCart setting is active."
And CALL SCOFF:
"Turns off the SuperCart emulation. This is the default state after reset or power-up."
Finally, CRU >1B16 is used to turn on/off the SuperCart banking. This comprises what I know about the HSGPL SuperCart handling.
So my question is:
Is SuperCart banking the same as SuperSpace II banking? SuperSpace II contains an Editor/Assembler GROM and 32 K RAM as 4 banks of 8 K, mapped into 6000, and selected by CRU setting at 0800.
Michael
-
Hi Jacques,
you're right ... the supercard mode was never implemented by Raphael Nabet who originally wrote the HSGPL, and I just forgot to add it. The manual is not very verbose in that respect, so I need some more time for that. Apart from the supercart emulation, the rest should be available.
-
I just meant to say that you can plug in a SCSI card (aka host adapter) in the PC and then detach the SCSI drive from the TI/Geneve and attach it to that host adapter, and back again - but not at the same time. I am not so sure whether the devices on the SCSI bus are equivalent or whether there is master/slave relationship.
-
What I found extremely useful with SCSI is that you just need to plug a host adapter into your PC and then you can swap the drive between the PC and the TI / Geneve. I did that in order to create the hard disk images for my MESS installation.
Of course, in that respect, Linux is a much better choice than Windows with its system tools like dd, so I just do a "dd if=/dev/sdX of=contents.dump bs=512" and for writing back, if/of swapped.
-
In my Fractals program which I wrote for the Geneve with its 9995, I designed some fixed point mathematics with 1 word integer and 3 word fraction part and managed to put the whole addition and multiplication routine into the 256 byte on-chip RAM, together with a workspace. Yes, THAT was a speed-up, you bet.
-
I have also seen some assembly books recommend the bad practice of reserving 32 bytes for your workspace with BSS, then setting the WP to that address. The problem with this is that the reserved memory, on the 99/4A, will be in 8-bit RAM and will be very slow for register access.
Not really bad practice, but rather a way to get a modular software design. This way you can write code modules to be linked together, each one with its own workspace, without bothering about which memory location to use, so you can later call it with BLWP. You're certainly right that this means a significant slowdown if you do not use the console-internal 16 bit mod.
-
One thing I wanted to add to this discussion: This was a similar situation with the introduction of the Geneve. Luckily it is compatible enough to run the old software, but it has so much potential which has never been exploited. This would have been a hardware platform which could have gained some broader support in the TI community, as a common, next-generation solution. The issue is always that you cannot really rely on all people buying the same extensions, and this makes it almost impossible to write programs for a larger audience. As with the F18A here, it does not address me. Indeed, I believe it is an impressive, remarkable project, but I just don't have a TI console anymore, just my Geneve.
I recently had a somewhat related idea. You know that MESS has some similarities with a breadboard in the sense that you can take the available emulated chips and plug them together. Not much more is done for the included emulations of the 99/4, 99/4A, 99/8, and Geneve. I learned a bit about the TMS99000 recently (while I prepared some slides for my operating system lecture, topic "privileged mode") and started to dream about what would have been possible with such a CPU. At this time we don't have an emulation for the TMS99105 or 99110, but with the implementations of the 9900 and 9995 this would not be that difficult. And then, what about plugging together some parts, for instance, this CPU together with the V9938, a memory mapper chip, a PC keyboard interface, and, say, 16 MiB of RAM.
It could work. And it would be available at no cost for everyone interested. But on the other hand I say, is there enough sense in it? Would it be worth the hours to create a new, fascinating multitasking environment for a fictional computer?
I heard people saying that emulations are not "the real thing". Is that so? From a hardware point of view, sure. But most of us have been working on the software side, and software as such is just information, whether executed by real hardware or by emulation.
It is a question what are our motivations to still work with this platform. And one reason could be just the wish to prove what can be done with this platform, with its limitations from 30 years ago. Many things are no big challenges on today's platforms, but they are on our good old TI.
So where was my point ... ah yes. We can certainly build new extensions for the TI, also in the sense to do what is possible. Why not! And people may use them. But we cannot make others follow that path, so we won't establish a new, broad platform to write software for everyone. After all, we don't do that to earn our living, do we?
-
OK, after some first tests my intermediate results:
Do NOT use the BwG controller but only the HFDC until this has been resolved. I already noticed some days ago that the original TI controller does not work properly anymore, so it is quite likely that the BwG has similar problems, since both controllers make use of the same controller chip family (WD17xx), while the HDC9234 chip only appears on the HFDC, so no one except me has been working on it.
The floppy system has been worked on by the other devs already some months ago, and I did not have the time to catch up. So we're running on some legacy code here.
-
Hello Jacques, the default DIP setting for BwG is "DSK1 only". Have a look at the setting (ScrollLock, Tab, DIP switch settings). I just decided to change the default to DSK1-DSK4 since the "DSK1 only" default causes more trouble than necessary, so this will be available in subversion in a few minutes, and in the next MESS update.
MESS works perfectly with PC99 images. There could be issues for single-sided formats because PC99 seems to dump both sides, while only one side is expected in MESS, but if you use 360K disks (DSDD) there should be no problem.
NVRAM files are written when you stop the emulation.
QMC2 should work fine. Linux users generally prefer command lines because of the powerful shell environment.
You can send files to [email protected]
Michael
-
Hi Jacques,
do you experience these problems without Horizon RD as well? What controller are you using - I suppose HFDC? What tool do you use to copy a file from DSK3 to DSK2? Maybe you can send me a sample disk image with instructions how to reproduce the problem.
Michael
-
As for TIImageTool there is going to be a major new release in short term, maybe in two weeks or so, including the GPL disassembler, picture viewer, and the DIS/FIX 80 disassembler, which attempts to create code that can be assembled again. The D/F disassembler still needs some polishing.
-
2
-
-
As for the Geneve it uses a different Processor and is 8 bit so that is a whole other can of worms of a problem.
It is not more 8 bit than the TI-99/4A itself, just the databus multiplexer is built into the CPU. TI did a lot of things the right way here.
-
Edit: BTW, TI99dir works great in WINE
(for Michael mostly, but also for anyone that else that runs Linux with the WINE compatibility layer).I should say I have some ... well ... personal bias for my own TIImageTool
-
Essentially, you can consider the GPL interpreter as an 8-bit virtual machine, and GPL is its machine language.
-
Yes, CALL NEW is a subprogram of "Extended Basic Plus" or "Mechatronic/PS Extended Basic" (try in MESS with the cartridges "me_extended_basic.rpk" or "extended_basic_plus.rpk").
-
Strange indeed. I tested it with the BwG controller in MESS, and it seems to work as well. The TI FDC has a FD1771, while there is a WD1773 in the BwG (both the same family), but the HDC 9234 in the HFDC fails. So that's a direct controller access?
-
If you run into trouble, please report it to me. I hope we can eventually collect all tips to create a guide, simple to understand, which does not require indepth knowledge of compiling.
The problem as I saw it again and again, in particular with open-source software and Linux, is that the machines people work with differ to some higher degree than expected. Sometimes you simply don't know whether you have to tell someone to install some library because on your system, this library has been installed long ago. So you wonder why the other person runs into trouble while it is perfectly running for you.
I should say that all the devs do some good job in reviewing. You should not get a single warning during compile, which you cannot take for granted with many other projects. So if compile fails, you are missing a library, and it's a matter of a few package installations.
-
2
-
-
If you don't tell anyone then I'll disclose that all ROMs can be found on WhTech now.
Look for ti_family.zip in the emulators/mess/roms directory.Owen, when you build MESS, could you tell me what libraries you had to install? The problem is that I'm using openSUSE which may come with a different collection of libraries, so if I tell you what you need you may still fail to build it. If we know what is needed I can put that on ninerpedia.
Have a look at http://www.ninerpedia.org/index.php/Building_MESS which should guide you through the process. As written there I would always recommend to use the subversion repository, because it always contains the latest fixes.
Michael
-
3
-
-
If you want to do debugging in MESS, here are some tips. (I think I'll have to write that down somewhere.)
Start MESS with the option -debug. This will lauch a debugger window. The most important things to know are:
- F5: Run
- F11: Single step
There is a command line at the bottom right. Interesting commands are those for handling breakpoints.
- bpset <hexaddr>
- bpclear <bpnumber>
- bplist
When the execution reaches a breakpoint, it stops right there, after executing the line. You see the current workspace on the left.
You can open a memory dump window using the window menu or Ctrl-M. Note that earlier MESS versions had the issue that reading of GROMs or VDP was not blocked, so when you scrolled over these addresses, the emulated system would crash or react in some unforeseeable way. I fixed that in the latest release.
In the current case I would suggest to put a breakpoint at D01A, then enter Editor/Assembler and load and run FBFORTH. You can then continue setting more breakpoints and so on.
Michael
Like us on Facebook
Follow us on Twitter
AtariAge on Instagram
Watch us on YouTube
Chat on Discord
E/A Manual Addendum
in TI-99/4A Development
Posted
What is the issue you expect?
I would never really assume that the GROM address is unchanged after a DSR call. Apart from the fact that I only rarely needed access to the GROMs. The problem they are bringing up is that you could decide to set a GROM address, do some reads, do a DSR call, and then continue reading.