Subject: Emulator/Simulator disk type

From: "epergrem" <[email-masked]>
Date: Mon, 09 Nov 2009 16:07:18 -0000

Hi All,
I'm trying to put together a matrix of emulators/simulators and the disk type they use and sizes (if that's relavent).

For instance PC99 = .dsk (255kb, 537kb), v9t9 = .dsk (90kb, 180kb, etc.)
MESS = ??, Classic99 = ?, TI99-PC = .img (??, ??), etc.

I know that some use other formats (e.g. DOAD(?), FOAD(?)) and may not have a fixed fixed size.

The reason for the above is an attempt to bring some order to these type files on the WHT site.  For instance, if multiple programs use the v9t9 format, then it makes sense to consolidate these disks under one folder, rather than duplicate them.  The same would be try for DOAD, FOAD, etc.

Thanks,
Ernie

---

From: "Tursi" <[email-masked]>
Date: Mon, 9 Nov 2009 11:37:37 -0500

I'd rather see the files sorted by what they are, than what emulator 
reads them, myself. We have the tools today to make any file run on any 
emulator -- if it doesn't natively in the first place -- so sorting by 
emulator encourages duplication and increases the difficulty of finding 
something (for instance, a file which is only in the PC99 folder but you 
run MESS).

Just my two bits.

That said, Classic99 today supports only "FIAD" -- files in a directory, 
and no disk images at all. (DOAD is "Disk On A Disk" and is the .DSK 
format for V9T9. FOAD should be FIAD, but I think everyone gets the 
intent. :) )

> I'm trying to put together a matrix of emulators/simulators and the 
> disk type they use and sizes (if that's relavent).
> The reason for the above is an attempt to bring some order to these 
> type files on the WHT site.  For instance, if multiple programs use 
> the v9t9 format, then it makes sense to consolidate these disks under 
> one folder, rather than duplicate them.  The same would be try for 
> DOAD, FOAD, etc.
>

---

From: "epergrem" <[email-masked]>
Date: Mon, 09 Nov 2009 18:01:14 -0000

I agree, having only one copy would be the ideal, but I don't think that it's practical.

The only way to prevent multiple versions, meaning a v9t9 compatible version, a pc99 compatible version, a classic99 compatible version, etc., is to have a standard.

Early on that was true.  When Charles Good did the initial load of the system, all disks were in PC99 format.  

Since there were utilities that could convert 'from' PC99, but none that converted 'to' PC99, it made perfect sense.  However, others started uploading v9t9 versions, FIAD versions, etc., to share with those that didn't own PC99.

Multiple versions of a given disk are inevitable, so having a system to deal with it is the practical solution.

It seems to me that one way to deal with it is to recognize commonalities amongst emulators and try to minimize it.  If both M.E.S.S. and v9t9 use the same format disk, then it makes sense there should only be one copy.

---

From: "epergrem" <[email-masked]>
Date: Thu, 12 Nov 2009 13:45:13 -0000

From what I've been able to determine there are three types of files (disks) used with the current crop of emulator/simulators.

PC99 = (DOAD - PC99 format)
MESS,Win994a,V9T9,TI99/4w = (DOAD - v9t9 format)
Classic99, TI99/4w = (FIAD - individual files)

Did I miss anyone, or get any of this incorrect?

The next thing I would like to determine, which ones share similar formats for the modules?

Thanks,
Ernie

---

From: "Tursi" <[email-masked]>
Date: Thu, 12 Nov 2009 12:35:57 -0500

> >From what I've been able to determine there are three types of files 
> >(disks) used with the current crop of emulator/simulators.

Yes, V9T9 also uses FIAD, and there are two types of FIAD - V9T9 format 
(works with V9T9 and Classic99) and TIFILES format (works with 
Classic99). I don't know which types of FIAD TI994/w supports.

Please don't organize the program files on FTP site by file type at the 
top level... any file can be converted for any emulator with tools like 
TI99Dir. It encourages duplication and I feel it'd be harder to locate 
specific pieces of software. In addition, emulators still under 
development will change that mapping. For instance, Classic99 will 
eventually support both DOAD formats as well.

Rather than duplicating by file format it'd be nice to be able to browse 
by what the program is, and if necessary, break it down into the 
different formats at the last step. Which is more important? Where it 
runs or what it is?

> The next thing I would like to determine, which ones share similar 

Off the top of my head, I've seen modules as raw memory dumps, with and 
without GRAM Kracker and TIFILES headers, as well as PC99 format 
headers. V9T9 format is just the raw memory dump, and relies on the last 
letter of the filename for placement. Win994A has its own custom 
cartridge format, TICART, that I believe nobody else supports, and MESS 
has introduced the RPK with I believe for the moment only MESS supports, 
but this too is scheduled to change.

What supports what.. I can't speak with authority, but off the top of my 
head:

Raw memory dumps: MESS, V9T9, Classic99
w/TIFILES and/or GRAM Kracker header: Classic99
PC99 format: PC99
TICart: Win994A
RPK: MESS

Again, I can't speak for TI99/4w at all there, nor can I say I'm certain 
on the others.

---

From: "epergrem" <[email-masked]>
Date: Thu, 12 Nov 2009 18:20:17 -0000

Tursi,

Plans are to order the disks by 'program', not type. Within each program directory the disks will be as they are.  
 
The only change will be the suffix, which is necessary since there may be multiple versions (pc99, v9t9, etc.) of the same filename.  

The question is how to effective handle FIAD format, since they are individual files.  They could be dumped into the diretory, append a suffix (e.g. FIAD), be zipped ,or placed into a FIAD folder within the program folder.

The emulators directory/folder will only contain items 'specific' to the emulator.  That's why the question regarding module gram files, etc.  If multiple emulators/simulators share a common format then there shouldn't be multiple copies.

Ernie

---

From: R Halter <[email-masked]>
Date: Thu, 12 Nov 2009 12:40:42 -0600

epergrem wrote:
> 
> The question is how to effective handle FIAD format, since they are
> individual files.  They could be dumped into the diretory, append a
> suffix (e.g. FIAD), be zipped ,or placed into a FIAD folder within
> the program folder.

FIAD means individual files, right, as opposed to a complete disk image? 
  Maybe files that might normally be together on a disk could be zipped 
together, while files that normally are kept separate could just have 
[FIAD] added to the filename.

Another option could be to zip individual files, then rename the ".zip" 
to ".fiad," but then you'd probably have to have a text file or 
something, in the same directory, to let people know that these are just 
ordinary zip files.

Uhm...  okay, enough bad ideas from me.  I'm going back to experimenting 
with my console now...

-- 
"Which key is the 'Any' key?"

---

From: fdos <[email-masked]>
Date: Thu, 12 Nov 2009 11:50:13 -0700

MESS also supports the GramKracker format for the Geneve emulator in GPL 
mode.

Bill S

---

From: tursi <[email-masked]>
Date: Thu, 12 Nov 2009 11:16:49 -0800 (PST)

Good, thanks. I missed your reply the first time I mentioned this.

IMO, FIAD files might as well be zipped together. Then you can also 
include the type in the zip name. Even TIs can unzip. :)

---

From: tursi <[email-masked]>
Date: Thu, 12 Nov 2009 11:23:58 -0800 (PST)

Just combine the ideas, and append "_fiad.zip" to the zip file. If you 
rename the actual files, then everyone who downloads them simply needs to 
rename them back again, which adds an unnecessary step.

Since there are two types, I'd propose if the type is known, to use that, 
and to use FIAD if the type isn't known, so:

_fiad.zip -- collection of FIADs whose format was not investigated (or 
mixed?)
_v9t9.zip -- collection of FIADs in V9T9 format
_tifiles.zip -- collection of FIADs in TIFILES format

This way, clear ID and no renaming needed by the downloader.

---

From: "Michael Zapf" <[email-masked]>
Date: Sat, 14 Nov 2009 01:15:17 -0000

> V9T9 format is just the raw memory dump, and relies on the last 

Change? But only in the way that RPK will be the only cartridge format in MESS that enjoys care and further development. The new cartridge types (inverted 379, CRU) are only available via RPK, and I hope that at some time in future I can finally drop the raw dumps completely.

This is why I hope to convince you to support RPK in Classic99 so we have a common cartridge format. :-)

Michael

---

From: Brian Tristam Williams <[email-masked]>
Date: Sat, 14 Nov 2009 03:17:36 +0200

Hey Michael, good to see your name again!

2009/11/14 Michael Zapf <[email-masked]>

> Change? But only in the way that RPK will be the only cartridge format in
> MESS that enjoys care and further development. The new cartridge types
> (inverted 379, CRU) are only available via RPK, and I hope that at some time
> in future I can finally drop the raw dumps completely.
>

-- 
Brian Tristam Williams

"One man can make a difference."

---

From: "Michael Zapf" <[email-masked]>
Date: Sat, 14 Nov 2009 01:17:12 -0000

--- In [email-masked], fdos <fdosbrs@...> wrote:
>
> MESS also supports the GramKracker format for the Geneve emulator in GPL mode.

Yeah, but it's not MESS - it's the GPL mode which supports the GK format. Like in the real hardware.

Michael

---

From: "Michael Zapf" <[email-masked]>
Date: Sat, 14 Nov 2009 01:23:37 -0000

> The reason for the above is an attempt to bring some order to these type files on the WHT site.  ...

Some months ago I brought up the discussion whether to give proper names to formats. I'm still favoring something like "sector dump format" instead of "v9t9" format and "track dump format" for "pc99". We could also consider to introduce a suffix "dtk" ("disk tracks") beside "dsk" (disk sectors) so that we can tell them apart more easily. 

Still not convincing?

Michael

---

From: fdos <[email-masked]>
Date: Fri, 13 Nov 2009 18:29:14 -0700

So there won't be any change for the MESS emulation of the Geneve in GPL 
mode?  I don't suppose there's any hope of getting the new expanded cart 
formats for GPL mode?

Bill S

Michael Zapf wrote:
>  
> 
> 
> 
> --- In [email-masked] <mailto:TI994A%40yahoogroups.com>, fdos 
> <fdosbrs@...> wrote:
>  >

---

From: tursi <[email-masked]>
Date: Fri, 13 Nov 2009 17:50:25 -0800 (PST)

> Change? But only in the way that RPK will be the only cartridge format

Please read more carefully. I did not say MESS was going to change, I said 
Mess being the only supporter of RPK was going to change. I announce 
Classic99 would get support when I could do it some time ago. :)

---

From: "Tony Knerr" <[email-masked]>
Date: Sat, 14 Nov 2009 02:08:44 -0000

> mode?  I don't suppose there's any hope of getting the new expanded cart 

So you're asking for a major rewrite of the MDOS GPL program, Bill?
Including a way to get the new expanded cart files from PC format into TI/Geneve format and into the emulated hard drive. Quite a task,
IMHO nearly impossible for any of us mere mortals.

Tony

---

From: fdos <[email-masked]>
Date: Fri, 13 Nov 2009 19:19:46 -0700

Tony,

Real dreamers dream big.  Anything in GPL is beyond me, so I can only 
ask for what I dream up.  I understand that we have not because we ask 
not.  So I always ask.  Usually, a lot more than once.

How about just 64K of bank switchable RAM at >6000 ~ >7FFF in 8K segments?

Bill S

Tony Knerr wrote:
> Including a way to get the new expanded cart files from PC format into 
> TI/Geneve format and into the emulated hard drive. Quite a task,

---

From: "Tony Knerr" <[email-masked]>
Date: Sat, 14 Nov 2009 02:46:27 -0000

> Some months ago I brought up the discussion whether to give proper names to formats. I'm still favoring something like "sector dump format" instead of "v9t9" format and "track dump format" for "pc9…

The idea makes a lot of sense to me, Michael.

At this point in time, it seems most emulators for the TI are using the sector dump format. The track dump format used by PC99 is the lone
emulator sharing the .dsk extension, and PC99 is no longer under active development. It might be prudent to rename PC99 .dsk files to .trk files to distinguish between the two formats. Since PC99
only runs in DOS/Windows, it's quite a simple task for those users to change the .trk extension to .dsk for disk dumps in that environment.

But just because you and I think it's a good idea doesn't mean everyone else will. :)

Tony

---

From: Insane Multitasker <[email-masked]>
Date: Fri, 13 Nov 2009 21:09:47 -0600

Hi folks,

I'm looking for some AMS items.  I seem to recall a program by Brad Snyder that had the ability to load multiple XB programs into the AMS and "flip" between them.  I want to do something similar and am looking for the program and example code.  Thanks

 
 		 	   		  
_________________________________________________________________
Windows 7: Unclutter your desktop.
http://go.microsoft.com/?linkid=9690331&ocid=PID24727::T:WLMTAGL:ON:WL:en-US:WWL_WIN_evergreen:112009

---

From: "epergrem" <[email-masked]>
Date: Sat, 14 Nov 2009 03:16:52 -0000

While PC99 might not be in 'active' development, it still has a good many users.  

It is also the predominant format on the WHT site and there are close to 100,000+ disks that use the .dsk suffix amongst PC99 owners.  I know, I distributed the CDs. :-)

Plans for WHT are to leave the PC99 disks as is and rename what V9T9 disks there are to .V9.  It's nothing again V9T9 users.  It's simply that there are less V9T9 disks to locate and rename.

Ernie

---

From: "Tony Knerr" <[email-masked]>
Date: Sat, 14 Nov 2009 03:17:16 -0000

--- In [email-masked], fdos <fdosbrs@...> wrote:
> Real dreamers dream big.  
> ...

Why do you want to limit yourself to much less than is currently available? Just use the banking scheme already in place in GPL mode. 

Tony

---

From: fdos <[email-masked]>
Date: Fri, 13 Nov 2009 22:07:17 -0700

That requires me to do the programming.  I just want to load the new 
cartridges, as I rarely program in GPL mode.

Bill S

Tony Knerr wrote:
> Why do you want to limit yourself to much less than is currently 
> available? Just use the banking scheme already in place in GPL mode.
> 
> Tony
> 
>

---

From: "jhwhite_delphi" <[email-masked]>
Date: Sat, 14 Nov 2009 05:20:33 -0000

IIRC, in GPL mode the banking at >6000-7FFF only works correctly if pages >36 and >37 are used.  If write-protection is off, page >36 is usable as RAM.  If write-protection is on, writes to >6000 load page >36 and writes to >6002 load page >37.  For XB, the "ROM" at >6000-6FFF in pages >36 and >37 contain identical code, while the "ROM" at >7000-7FFF in pages >36 and >37 contain different code.

For Mini Memory, >6000-6FFF is write-protected, but >7000-7FFF is not write-protected to allow its use as RAM.

What I do not recall is if writes to >6000 and >6002 when >6000-6FFF is write-protected, but >7000-7FFF is not, bank between pages >36 and >37.

GPL mode does some squirrelly things.

Jeff White
[email-masked]

--- In [email-masked], "Tony Knerr" <tonyknerr@...> wrote:
>
> 
> --- In [email-masked], fdos <fdosbrs@> wrote:
> >
> > Tony,
> > 
> > Real dreamers dream big.  
> > ...
> >

---

From: "Tony Knerr" <[email-masked]>
Date: Sat, 14 Nov 2009 11:26:58 -0000

That, of course, is the traditional way it's done.

Since the memory map is available to GPL mode, one can bank in any available page to the 'cartridge' space from >6000->7FFF.
So Bill can use much more than the 64k he was looking for if he
does his banking via the memory map.

Tony

--- In [email-masked], "jhwhite_delphi" <jhwhite@...> wrote:
> jhwhite@...

---

From: "Michael Zapf" <[email-masked]>
Date: Sat, 14 Nov 2009 12:14:54 -0000

> Classic99 would get support when I could do it some time ago. :)

Reading that way ... yes, agree, sorry. But you have to admit that it was ambiguous. :-)

Michael

---

From: "Michael Zapf" <[email-masked]>
Date: Sat, 14 Nov 2009 12:44:57 -0000

> Plans for WHT are to leave the PC99 disks as is and rename what V9T9 disks there are to .V9.  It's nothing again V9T9 users.  It's simply that there are less V9T9 disks to locate and rename.

Hmmm ... do we actually have current v9t9 users? (Honestly asking, don't misunderstand that.)

The sector dump format (aka v9t9 format) is currently the only floppy format supported by MESS. That is, people using that format are probably more MESS users rather than v9t9 users. I'm planning to write support for track dumps as well so MESS can also make use of the PC99 disks, but that may take some time.

But I do not agree with renaming "dsk" to "v9". Not only would this mean that I have to change suffixes in the TI MESS emulation (which is not a hard problem, but unnecessary) and rename all my disk images in my own disk repository ... I just don't see much sense in naming files after an admittedly good but dated and non-supported emulator. Such a naming implies that this format is intended mainly for v9t9, and why should I explain to new MESS users that they have to take a disk format named after another emulator?

I think I could live with a suffix "sdf" as "sector dump format" for the "v9t9" format. That's a neutral name which at the same time is more informative about the format. Within MESS we'll use an auto-detect as soon as more formats are supported.

Michael

---

From: "Michael Zapf" <[email-masked]>
Date: Sat, 14 Nov 2009 13:05:29 -0000

Hello Bill,

> mode?  I don't suppose there's any hope of getting the new expanded cart 

I think I understand what you would like to get, but I'm not sure whether this makes sense within an emulator like MESS.

First to say: MESS is an emulator which strives for precise mapping of the hardware. Therefore, MESS will never show features which were not present in the real hardware. You'll never get five visible sprites in a row, no interesting new processor commands, and the Geneve emulation will never have a cartridge slot since the real Geneve never had one. If you show me hardware which does it - no problem, let's emulate it. (Well, almost. :-) )

Once someone on the MESS forum explained the rationale of MESS: It's a documentation. That's true in some sense - it's an executable documentation of arcade and home computer systems. The ultimate goal (which I believe will not be that easy to achieve) is to be able to "build" a system by means of a textual description, like an XML file. This is an exciting idea. You could indeed end up in reading the schematics into the system and have them executed (in some future time).

So back to the problem. What you ask for is to be able to plug in a cartridge, which in GPL mode is automatically recognized as being loaded as a collection of GK files. But the GPL mode manager in the Geneve wants to load the files from disk - how can I convince it that the files are already present via the emulation? You see - supporting "cartridges" in the GPL mode would not mean to implement this in the MESS emulation, but rather modify the behavior of the Geneve GPL mode manager, and this is out of reach for MESS. MESS simply does not know what a "GPL mode" is.

Michael

---

From: fdos <[email-masked]>
Date: Sat, 14 Nov 2009 07:42:07 -0700

Michael,

I understand.  I've been barking up the wrong tree.  I should have known 
this, so my apologies while I go wash more egg off my face.  I need to 
take this request to the MDOS/GPL developers, as it is not a MESS issue.

Thanks for taking the time to explain to this dunce.

Bill S

Michael Zapf wrote:
> I think I understand what you would like to get, but I'm not sure 
> whether this makes sense within an emulator like MESS.
> 
> First to say: MESS is an emulator which strives for precise mapping of 
> the hardware. Therefore, MESS will never show features which were not 
> present in the real hardware. You'll never get five visible sprites in a 
> row, no interesting new processor commands, and the Geneve emulation 
> will never have a cartridge slot since the real Geneve never had one. If 
> you show me hardware which does it - no problem, let's emulate it. 
> (Well, almost. :-) )
> 
> Once someone on the MESS forum explained the rationale of MESS: It's a 
> documentation. That's true in some sense - it's an executable 
> documentation of arcade and home computer systems. The ultimate goal 
> (which I believe will not be that easy to achieve) is to be able to 
> "build" a system by means of a textual description, like an XML file. 
> This is an exciting idea. You could indeed end up in reading the 
> schematics into the system and have them executed (in some future time).
> 
> So back to the problem. What you ask for is to be able to plug in a 
> cartridge, which in GPL mode is automatically recognized as being loaded 
> as a collection of GK files. But the GPL mode manager in the Geneve 
> wants to load the files from disk - how can I convince it that the files 
> are already present via the emulation? You see - supporting "cartridges" 
> in the GPL mode would not mean to implement this in the MESS emulation, 
> but rather modify the behavior of the Geneve GPL mode manager, and this 
> is out of reach for MESS. MESS simply does not know what a "GPL mode" is.
> 
> Michael
> 
>

---

From: fdos <[email-masked]>
Date: Sat, 14 Nov 2009 07:51:42 -0700

Tony,

I have no desire to program in GPL mode in any language.  I was just
hoping to save/load GK versions of the new expanded cartridge formats.

Jeff White has made it clear as to how the cartridge RAM in GPL mode is 
handled currently, and even I can see that it would be quite a task to 
revamp that to accomplish my request, so not likely to happen in this 
century.

No harm in asking, right?

Bill S

Tony Knerr wrote:
> Since the memory map is available to GPL mode, one can bank in any 
> available page to the 'cartridge' space from >6000->7FFF.
> --- In [email-masked] <mailto:TI994A%40yahoogroups.com>, 
> "jhwhite_delphi" <jhwhite@...> wrote:
>  >
>  >
>  >
>  > IIRC, in GPL mode the banking at >6000-7FFF only works correctly if 
> pages >36 and >37 are used. If write-protection is off, page >36 is 
> usable as RAM. If write-protection is on, writes to >6000 load page >36 
> and writes to >6002 load page >37. For XB, the "ROM" at >6000-6FFF in 
> pages >36 and >37 contain identical code, while the "ROM" at >7000-7FFF 
> in pages >36 and >37 contain different code.
>  >
>  > What I do not recall is if writes to >6000 and >6002 when >6000-6FFF 
> is write-protected, but >7000-7FFF is not, bank between pages >36 and >37.
>  >

---

From: Insane Multitasker <[email-masked]>
Date: Sat, 14 Nov 2009 12:19:08 -0600

I believe you are correct; I seem to recall the gate array was configured to use these two pages specifically.  The pages are locked via CRU setting.  I ran into this situation with EXEC -- I got around it by dumping the contents of page >36 to a free page of RAM if MDOS had already claimed the page, thus allowing its use temporarily while operating in TI (GPL) mode, and ultimately restoring upon return to MDOS.  Page mapping could be handled in this fashion and Tony's suggestions could be tested - both might yield creating handling for Bill.  But emulating the 64K cart on the Geneve would be troublesome at best. IMHO. 

> To: [email-masked]
> From: [email-masked]
> Date: Sat, 14 Nov 2009 05:20:33 +0000
> Subject: [TI994A] Re: Emulator/Simulator disk type
> 
> 
> 
> ------------------------------------
> 
> Yahoo! Groups Links
> 
> 
> 
 		 	   		  
_________________________________________________________________
Windows 7: I wanted simpler, now it's simpler. I'm a rock star.
http://www.microsoft.com/Windows/windows-7/default.aspx?h=myidea?ocid=PID24727::T:WLMTAGL:ON:WL:en-US:WWL_WIN_myidea:112009

---

From: "Tursi" <[email-masked]>
Date: Sat, 14 Nov 2009 15:22:09 -0500

>> Plans for WHT are to leave the PC99 disks as is and rename what V9T9 
>> disks there are to .V9.  It's nothing again >>V9T9 users.  It's 
>> simply that there are less V9T9 disks to locate and rename.
> But I do not agree with renaming "dsk" to "v9". Not only would this 
> mean that I have to change suffixes in the TI MESS
>emulation (which is not a hard problem, but unnecessary) and rename all 
>my disk images in my own disk repository ... I
>just don't see much sense in naming files after an admittedly good but 
>dated and non-supported emulator. Such a naming
>implies that this format is intended mainly for v9t9, and why should I 
>explain to new MESS users that they have to take a
>disk format named after another emulator?

Not only MESS, but TI99Dir as well. I don't personally agree with any of 
the renaming plans, it means that anyone who downloads the disk (no 
matter what they use and no matter which scheme you take) has to rename 
the file before they can use it.

Just put the tag /BEFORE/ the extension, don't change the extension. 
MYDISK_PC99.DSK or MYDISK_V9T9.DSK (or TRK or whatever else tag you 
want - if you don't mess with the extension then it's not going to 
impact anyway. :) ) Even people still using V9T9 can use the image 
directly then (they just have to use the short name form for DOS).

Classic99 will be autodetecting when it gets support added as well.

---

From: "epergrem" <[email-masked]>
Date: Sat, 14 Nov 2009 22:40:30 -0000

Michael,
There are likely very few, if any V9T9 users today, but I use the term because it's where the 'sector dump format' originated, although the format is used by multiple simulators now.

Ernie

---

From: ti99_forever <[email-masked]>
Date: Sat, 14 Nov 2009 14:52:46 -0800 (PST)

I actually do, sometimes.
There are some programs that run better on V9T9 than on PC99. And both emulators run great under DosBox. More of a convenience, when I'm on my Mac.

--- On Sat, 11/14/09, epergrem <[email-masked]> wrote:

From: epergrem <[email-masked]>
Subject: [TI994A] Re: Emulator/Simulator disk type
To: [email-masked]
Date: Saturday, November 14, 2009, 5:40 PM

  

      Michael,

Ernie

---

From: "jhwhite_delphi" <[email-masked]>
Date: Sun, 15 Nov 2009 01:10:00 -0000

I suppose some tests are in order.

If cartridge space is protected, the "ROM" banks are in pages >36 and >37.

If cartridge space is unprotected, there is no automatic banking.  Can any page become visible at >6000-7FFF by writing to mapper register >8003?

If >6000-6FFF is protected and thus bankable between pages >36 and >37, but >7000-7FFF is unprotected, can you window into different pages at >7000-7FFF by changing the mapper register >8003?

Jeff White
[email-masked]

> does his banking via the memory map.
<snip>

---

From: fdos <[email-masked]>
Date: Mon, 16 Nov 2009 08:47:46 -0700

Jeff,

I've seen no reply to your proposal.  I would be willing to do it if I 
could do it quickly--which means in Forth, but I don't have access to an 
old enhanced Forth that would work in GPL mode right now.  They would be 
on a SCSI drive or on 5.25" diskettes still out in the garage, and 
currently I'm in the process of reworking my SCSI bus cable chain 
arrangement.

This means I can only do it if someone supplies a simple program that 
does the necessary testing and verification.

Bill S

jhwhite_delphi wrote:
> If cartridge space is unprotected, there is no automatic banking. Can 
> any page become visible at >6000-7FFF by writing to mapper register >8003?
> 
> If >6000-6FFF is protected and thus bankable between pages >36 and >37, 
> but >7000-7FFF is unprotected, can you window into different pages at 
>  >7000-7FFF by changing the mapper register >8003?
> 
> Jeff White
> [email-masked] <mailto:jhwhite%40delphiforums.com>
> 
> --- In [email-masked] <mailto:TI994A%40yahoogroups.com>, "Tony 
> Knerr" <tonyknerr@...> wrote:
>  >

---

From: "Tony Knerr" <[email-masked]>
Date: Mon, 16 Nov 2009 17:08:50 -0000

> does the necessary testing and verification.
Bill, this will do it:

ftp://ftp.whtech.com/utilities/MEMEDIT.DSK

I was going to try all of the possibilities Jeff suggested, but haven't gotten a chance yet. I know that some of the banks can be swapped, like >A000 and up, because I've done it in the past. I had a short program that swapped out high memory, where I had DSKU stashed in a few other banks, so I could load it instantly, and then go back to what I was doing previously. But that was a few years ago...

Tony

---

From: fdos <[email-masked]>
Date: Mon, 16 Nov 2009 11:13:28 -0700

Tony,

Does it have docs or on screen prompts?

Bill S

Tony Knerr wrote:
> <ftp://ftp.whtech.com/utilities/MEMEDIT.DSK>
> 
> I was going to try all of the possibilities Jeff suggested, but haven't 
> gotten a chance yet. I know that some of the banks can be swapped, like 
>  >A000 and up, because I've done it in the past. I had a short program 
> that swapped out high memory, where I had DSKU stashed in a few other 
> banks, so I could load it instantly, and then go back to what I was 
> doing previously. But that was a few years ago...
> 
> Tony
> 
>

---

From: Tony Knerr <[email-masked]>
Date: Tue, 17 Nov 2009 08:13:13 -0500

> Does it have docs or on screen prompts?
Bill, It's the memory editor 'lifted' from the Pgram dsr, so you could 
look at the Pgram docs if you're not certain.
It's very similar to the Gram Kracker memory editor, if you're familiar 
with that.

Tony

---

From: fdos <[email-masked]>
Date: Tue, 17 Nov 2009 08:25:43 -0700

Tony, yes.  Thanks.

Bill S