Pascal on the 99/4A

[+Atari2600PAL]

2 minutes ago, apersson850 said:

No, it's not too much. What's imperative is that the PASCAL file is not only transferred, but that it ends up in exactly the same sectors as it originally occupied on the disk it was copied from. Which it normally does, if you copy it to an empty disk.

 

This is due to the fact that the PASCAL file is never used by the p-system. It's there just as a dummy file, to mark the diskette as fully used. The p-system instead accesses certain sectors on the disk, where it has its own file system with directory and files.

Thank you, I’ll prepare a disk then and see how I get on when the card arrives

 

Many thanks @apersson850

[apersson850]

Once the p-code card is in the box, the p-system will start even without any disk at all. There's a "GROM-disk" on the card that makes it start.

But you can't do too much useful with it without disk based software.

[+Atari2600PAL]

10 minutes ago, apersson850 said:

Once the p-code card is in the box, the p-system will start even without any disk at all. There's a "GROM-disk" on the card that makes it start.

But you can't do too much useful with it without disk based software.

Ok, thanks

[+Atari2600PAL]

My p-code card has arrived and appears to be functional, thankfully

 

However, it won't seem to work with the TIPI-PEB card fitted in the PEB (whether or not the PI is on or off)

 

Am I missing something obvious please? Do CRU bases or something come into play here or is it a known problem please?

 

With the TIPI-PEB removed it accesses the hard drives when I select 'E' for edit but it complains it can't find the EDITOR

 

I'm assuming it doesn't like the disk I made so will try making another

 

Many thanks 

[+Atari2600PAL]

2 minutes ago, Atari2600PAL said:

My p-code card has arrived and appears to be functional, thankfully

 

However, it won't seem to work with the TIPI-PEB card fitted in the PEB (whether or not the PI is on or off)

 

Am I missing something obvious please? Do CRU bases or something come into play here or is it a known problem please?

 

Sorry. It does boot up with the TIPI-PEB installed, it just doesn't try to access the physical disk drives at any point

[+Atari2600PAL]

Is this solution from @jedimatt42 in my PEB thread likely to be a solution please? (rather than having to remove TIPI-PEB each time)

 

"The floppy controller CRU base is 0x1100. The TIPI CRU base in your configuration should be 0x1000, and with the switch closed, 0x1800."

 

Many thanks

[+TheBF]

4 minutes ago, Atari2600PAL said:

Is this solution from @jedimatt42 in my PEB thread likely to be a solution please? (rather than having to remove TIPI-PEB each time)

 

"The floppy controller CRU base is 0x1100. The TIPI CRU base in your configuration should be 0x1000, and with the switch closed, 0x1800."

 

Many thanks

A conflict in the CRU addresses or incorrect address settings on the devices is a very probable cause.

 

My understanding: 

The TI  DSR system searches these cards in order of their CRU address to find the function requested by a program. (1000,1100,1200...) 

There can be cases where we want specific cards to be searched in a specific order or things won't work correctly.

In most cases TIPI needs to be first in line. 

 

[+Atari2600PAL]

34 minutes ago, TheBF said:

A conflict in the CRU addresses or incorrect address settings on the devices is a very probable cause.

 

My understanding: 

The TI  DSR system searches these cards in order of their CRU address to find the function requested by a program. (1000,1100,1200...) 

There can be cases where we want specific cards to be searched in a specific order or things won't work correctly.

In most cases TIPI needs to be first in line. 

 

It does seem to be CRU base related, but it seems like the p-code card finds the tipi (0x1000) and then doesn't fall forward to the FDC (0x1100)

 

I've jumpered the TIPI high CRU pins and now the p-code card is finding the physical drives with the TIPI installed

 

I guess I'll have to buy a switch as per @jedimatt42 suggestion in my peb thread (with regards to preventing tipi-peb blocking when PI powered off)

 

 

[+Atari2600PAL]

My system disk problem was because I formatted it as DSDD

 

Reformatted the disk as SSDD and it now accepts the disk

 

My cc9900 won't let me format a DSDD disk as SSSD so I can't create the individual disks, but I'll plug in my spare PHP1240 in the hope it might let me create the individual disks?

 

'E' for Editor launches (but I don't yet know how to use it), but 'R' for run gives me "bad data"

 

I need to read up on what is on the disk images etc. so I can create the disks to write a test program and prove it's all working

[+arcadeshopper]

1 hour ago, Atari2600PAL said:

It does seem to be CRU base related, but it seems like the p-code card finds the tipi (0x1000) and then doesn't fall forward to the FDC (0x1100)

 

I've jumpered the TIPI high CRU pins and now the p-code card is finding the physical drives with the TIPI installed

 

I guess I'll have to buy a switch as per @jedimatt42 suggestion in my peb thread (with regards to preventing tipi-peb blocking when PI powered off)

 

 

I tend to move my tipi to 1800 to get it  'out of the way' for anything trying to use it.. that said, it should fall over if you have nothing mapped to DSK1. DSK2. DSK3. etc when it is on 1000.. though if you put tipi at 1100 and take out your disk controller it can be used for pascal without issue (mapping the appropriate drives to disks)

[+Atari2600PAL]

1 minute ago, arcadeshopper said:

I tend to move my tipi to 1800 to get it  'out of the way' for anything trying to use it.. that said, it should fall over if you have nothing mapped to DSK1. DSK2. DSK3. etc when it is on 1000.. though if you put tipi at 1100 and take out your disk controller it can be used for pascal without issue (mapping the appropriate drives to disks)

Thanks @arcadeshopper

 

I have no mappings on the tipi, so not sure why it's not falling over. As I don't have any need, currently, to map floppy drives I'll leave it jumpered at 1800 for now

 

Though mapping it to 1100 (with FDC removed) may be useful for testing if the other problems are with the disks I create or the p-card

 

Many Thanks

[+Atari2600PAL]

Bingo

 

I used TI Disk Manager 2 and it let me format the disk as DSSD and I copied the pascal file from whtech's 705.dsk and the system now seems to run ok (other than when setting the date as it won't accept anything later than 1999, that pesky millennium bug still lives it seems)

 

Have run a cable from the tipi so I can change CRU without opening up the PEB (though will leave it at 1800 for now)

 

Many thanks

[+arcadeshopper]

The tipi log may be helpful.. why don't you grab it from the web interface and post it to the tipi support topic here: 

 

[+Atari2600PAL]

15 minutes ago, arcadeshopper said:

The tipi log may be helpful.. why don't you grab it from the web interface and post it to the tipi support topic here: 

 

Done

[apersson850]

The standard p-system will use only one storage (disk) controller at a time. It will pick the first one it can find, scanning the CRU base addresses, that supports sector read/write and then assume all used drives are handled by that controller. It will only work with controllers supporting direct sector access. It will never continue looking for a disk controller with a higher CRU base address than the first one found, regardless of if the first one has any disks or not.

Although the p-system in general can handle up to six drives, the system for the 99/4A is preconfigured to handle three drives, since that's what the TI controller can do. To use four (or more) drives they still have to be handled by the same controller and some system tables have to be patched. To handle more than one disk controller, additional system tables have to be created and manually mapped to the additional controller. Necessary to support both a RAM-disk and a physical controller, for example. In theory space can be allocated in VDP RAM for the additional controllers, but since all of the available memory must be there for the Editor to work, it's not feasible in reality. Instead you have to host these additional tables in the character or sprite definitions, some which you don't use.

 

The disks to use must have a p-system disk directory on them. The p-system is able to handle SSSD, SSDD, DSSD and DSDD disks, as long as the controller can do that. The program dformat supplied with the p-system claims it can support all the options, but it can't. But that doesn't matter - you can do it just as well with Disk Manager 2 or any other disk manager. First you format the disk so it's physically useful, then you use the Filer to Zero the disk, which is p-system terminology for creating the disk directory. The disk size is measured in blocks, each block being half a kilobyte. In this particular case it will also create a dummy file called PASCAL and claim that file occupies the whole disk. It's never used, but is there just so the disk looks occupied, should you attempt to use it with the ordinary operating system.

 

There are several system programs that can be invoked by pressing the associated key from the system prompt. E for Editor, C for Compiler and so on. For these programs to run, the files SYSTEM.EDITOR, SYSTEM.COMPILER, SYSTEM.FILER, SYSTEM.ASSMBLER or SYSTEM.LINKER must be accessible on some disk. Any disk will do - the system will scan all disks until these files are found.

To use R for Run a file named *SYSTEM.WRK.CODE must be available. If it isn't, the p-system will instead look for *SYSTEM.WRK.TEXT, compile it and then run the compiled code. If neither can be found there will be an error. The asterisk is a prefix, not part of the file name, indicating that the file is on the system disk, which always is drive number one, i.e. the one normally responding as DSK1. The p-system will refer to it as unit #4.

To run any other code file than the system files you use the command X for eXecute instead. So if you have the program dformat.code on the disk in the second drive, you can type X and then #5:dformat to run it. Or if you have a funny program stored on a cool disk then X followed by cooldsk:funnyprog will run it from that disk, regardless of which drive it's put into.

 

The p-system uses only two digits for the year in the date. Just enter 1923 and you're fine. The digits "19", when shown, are in the program displaying the date, not in the date itself. I've patched my system files that do display dates to replace "19" by "20". Works fine, except it will show the wrong date for very old files.

Edited August 14, 2023 by apersson850

[+Atari2600PAL]

Many thanks @apersson850 for all the information, much appreciated

 

Am going to resurrect an old iPad and just load it with the manuals and other references (don't want to kill a forest printing them out) so I can get my head around all this

 

To start with I think I need to find my way around the system 

 

e.g. The 705.dsk boots to filer and so far I've only got back out of that by pure chance...

 

Many thanks

[apersson850]

None of the system utilities (editor, filer, compiler, assembler or linker) start at booting by themselves. There's probably a program called *SYSTEM.STARTUP that executes the filer. Although the filer is started with the F command from the system menu, the p-system allows you to inject commands into the system's command processor from a running program. Hence it's possible to inject the command to start the filer, then quit your own program. The first thing that happens after your program stops is then to start the filer.

Press Q for quit to exit the filer program. By repeatedly pressing ? you can cycle through all options available in the menu in the top row.

 

To understand the p-system, if you've never used it before, is quite a handful. It's pretty different from the standard system in the TI 99/4A too. But you can ask questions here, and/or join the Facebook group TI 99/4A UCSD P-system, if you use Facebook.

To create your first Pascal program you may have use for this video.

Edited August 15, 2023 by apersson850

[+Atari2600PAL]

Thanks for the info @apersson850

 

The ? mark was a big bit I was missing, I wondered why I couldn’t find other command options! Will give it a go thanks

 

I’m not on any social media, in fact this site is the only site I’m a member on

 

Many thanks

[+TheBF]

1 hour ago, Atari2600PAL said:

I’m not on any social media, in fact this site is the only site I’m a member on

Truly, you are a wise man.

[+Atari2600PAL]

18 minutes ago, TheBF said:

Truly, you are a wise man.

I keep getting grief for not even joining the family WhatsApp…

[apersson850]

Here's another example of what you can do with the p-system, in spite of this not being intended by TI.

 

Graphics

[apersson850]

On 8/15/2023 at 2:14 PM, Atari2600PAL said:

The ? mark was a big bit I was missing, I wondered why I couldn’t find other command options! Will give it a go thanks

Any success in getting the first program to run yet?

[+Atari2600PAL]

Just now, apersson850 said:

Any success in getting the first program to run yet?

Hi @apersson850

 

Not had a chance to try anything as yet (am a full time carer so don’t get very much “me” time)

 

Will boot it up again when I get a bit of quite time (time today was spent fitting a cru switch to my tipi peb to be able to move it out of the way when using the p-code)

[apersson850]

Ah, the pesky thing called life...

[+FarmerPotato]

7 hours ago, apersson850 said:

Ah, the pesky thing called life...

I also appreciate your UCSD P-system videos. 
 

I have too much going on to play with one, but I do enjoy hearing about how the P machine runtime works. In particular, the code pools.
 

Did I understand correctly that user programs fill the VDP pool before going to expansion RAM? Seems strange to me. 

 

I've read much Niklaus Wirth in the past year, so new respect for Pascal. (Also Kernighan: Software Tools in Pascal.)