Jump to content
31336haxx0r

Any info on Video Technology Laser 500 computer?

Recommended Posts

It inspired me to try this hack on the good old C64:

$0900 SEI
$0901 LDA #$E2
$0903 STA $0318
$0906 LDA #$FC
$0908 STA $0319
$090B CLI
$090C RTS

While it doesn't have a checksum feature as on the Apple and the Laser, it could be a nifty trick to prevent someone hitting RUN/STOP + RESTORE.

Share this post


Link to post
Share on other sites

@Bonstra,

 

I am doing some ROM disassembly too (I'm at the very start) and I'm putting my findings in a repo as well:

 

https://github.com/nippur72/laser500emu/tree/gh-pages/docs

 

I am completely clueless about the FDC part, I tried to integrated the VZ200 FDC in my emulator but it doesn't work because the registers and the protocol seem to be different. And I got lost in the disassembly.

 

If you want we can modify the emulator so that we can mock the 0x10-0x1F I/O space responding with a JavaScript function for debug and simulation.

Share this post


Link to post
Share on other sites

@Bonstra I modified the emulator so it's easier for you to mock it

 

Just clone the `laser500emu` repo and modify "floppy.js".

function floppy_read_port(port) {
   console.log(`FDC read port ${hex(port)}h, pc=${hex(cpu.getState().pc,4)}h`);
   return 0x00;
}

function floppy_write_port(port, value) {
   console.log(`FDC write port ${hex(port)}h value ${hex(value)}h, pc=${hex(cpu.getState().pc,4)}h`);   
}

once you modify it, refresh the page and remember to power on/off the emulated Laser (alt+p)

 

FDC write port 10h value 00h, pc=6978h
FDC write port 13h value aah, pc=697bh
FDC read port 13h, pc=697dh
Edited by nippur72

Share this post


Link to post
Share on other sites

Two questions related to video vs cpu memory contention (@Bonstra's post)... I am stuck on these for the emulator:

1) are wait states inserted on every memory access, or are they limited only when the CPU wants to access the video memory (page 7) ? I am for all memory access, because the manual in the example talks about "opcode prefetch" which suggests a program in normal memory. This would also explain the lower average speed even when not working with memory. From my empirical tests, the Laser 500/700 runs at an apparent 2.6 MHz versus 3.67 Mhz theoretical.

2) are wait states inserted also when accessing I/O ports? In theory the bus is the same so it should be, but I am not sure.

Share this post


Link to post
Share on other sites

I think I have the answer to my previous questions: I get almost precise timings if I add one T-state for every memory or port access. Not only during the screen area as I thought, but always. This way I am able to get very close to the real hardware speed. It's not exact but it's very close. I guess I miss some other wait states somewhere.

Share this post


Link to post
Share on other sites

Hi!

 

I have been following this thread almost from the beginning (I noticed it since you have linked this post I wrote in Zona de Pruebas some time ago, and also my Flickr pictures), but I had nothing to add to your comments.

 

But I have seven Laser 700 floppies, and I had this comminment to dump them and share it with you, the commintment itching inside my head "I had to dump those disks, I had to dump them before it's to late" xD. Now I have read you need them badly and I have decided to relieve myself from this burden, so I have searched the disks, set up the KryoFlux device and I have produced seven floppy images. Five of them contain errors, but at least one "System Diskette" is (presumably) free of them.

 

45307890931_a96b057dc6_z.jpg

 

 

First of all, I had to guess which format had the disks. Laser 300 floppies use FM encoding, but according to my Zona de Pruebas' post, Laser 700 controller seems more similar to Apple II. I asked my friend Habi for help, and we have found the following tips:

 

- The controller IC should be the Toshiba TC17G005AP-0010 in this picture, a custom chip that may contain some code ( a "miniROM") to call the OS on the floppy (as in Amstrad PCW):

 

7615770488_8e495d83a8_z.jpg

 

- Laser 700 disks encoding is GCR. HxC software detects the raw fluxes from the disks as GCR*. If I set KF software to Apple DOS 3.3 sector image, it recognizes the format, although Apple II emulators won't find anything interesting on them (they report an error, actually).

 

You can find the disk images in Grupo de Usuarios de Amstrad FTP, here:

 

ftp://amstrad.serveftp.com/

user: amstrad

pwd: amstrad

folder: /Otros Sistemas/Laser 350-500-700

 

Image 4_s0.zip is a VT-DOS System Diskette with no errors. Images marked with and exclamation mark and the end of the name contain errors. If you need the fluxes, please let me know your email address by PM and I will send you a download link.

 

Hope this serves you!

 

 

*As you can see here:

31434562448_9e6efced49_z.jpg

Edited by deepfb
  • Like 3

Share this post


Link to post
Share on other sites

@deepfb WOW that's absolutely fantastic!!! Thank you very much! I could not hope better!

I will look into the disks to see what we can recover -- I'm excited!

Is there a tool to inspect those disk images? I'm not acquainted with floppies and you seem to know a lot about them :-)

Share this post


Link to post
Share on other sites

Although I have replied you by PM, I will try to give further details here.

 

CiderPress is not able to manage the disk images on the FTP (Apple II emulators just report errors). CiderPress is a program to edit Apple disk images, but it is not able to open the Laser images encoded as Apple GCR. Neither is able to open them Apple II Disk Browser.

 

For the fluxes, I produced them with KryoFlux. You can inspect them with the HxC software (just drop one of the files of the flux on it, and then click on "Track Analyzer").

 

I hope you will be able to extract the VT-DOS from the System Disk -but we keep in touch so I may help you with anything you may need! :)

Share this post


Link to post
Share on other sites

I managed to extract the VT-DOS aka DOS BASIC 1.0 from your disk images. It's only 5.6 Kbytes and it's replicated in almost all disks.

I've also disassembled the boot loader routine, it simply reads the first 22 sectors from the disk and places them in memory in page 6 (the 16K Ram that are not available to Basic).

 

@Bonstra do you need any of these for your work on the disk interface?

I'm also recovering the software from the other disks but many are corrupted. Soon I will post a report of what I managed to recover.

  • Like 1

Share this post


Link to post
Share on other sites

Now I have read you need them badly and I have decided to relieve myself from this burden, so I have searched the disks, set up the KryoFlux device and I have produced seven floppy images.

That's a really pleasant surprise icon_smile.gif

Thank you!

 

Did you use the Laser FD-100 to dump the disks? Do you know whether the FD-100 have 1 or 2 heads? According to the pinouts in the manual, pin 9 is SIDESEL (instead of -12V on the Apple Disk II). I'm curious to know whether the Laser FD-100 actually uses this signal.

 

@Bonstra do you need any of these for your work on the disk interface?

Having at least one valid disk image, it should be enough to be able to generate a simulated magnetic flux, and test it by letting the BASIC ROM boot the DOS from the emulated floppy.

Share this post


Link to post
Share on other sites

@Bonstra, disk #4 from the above download should be fine. The DOS itself is 5632 bytes and it is loaded in RAM in page 6 at the address 0xDE00 (when in bank 3) / 0x5E00 (when in bank 1). The boot sector is also copied in RAM because it needs to be written when a new disk is INITialized.

Share this post


Link to post
Share on other sites

This thread + the Facebook group really have exploded the interest for the Laser 500 / 700 (I suppose 350 too?) models in the past week(s).

Share this post


Link to post
Share on other sites

Did you use the Laser FD-100 to dump the disks? Do you know whether the FD-100 have 1 or 2 heads? According to the pinouts in the manual, pin 9 is SIDESEL (instead of -12V on the Apple Disk II). I'm curious to know whether the Laser FD-100 actually uses this signal.

 

No, I used a standard disk drive connected to KryoFlux to dump the disks. And the FD-100 has only one head:

 

45357768531_f0624c075a.jpg

 

I planned to connect the FD-100 to the Apple II just to check if it works, but I am going to discard that test: -12V going down the SIDESEL signal is not something I want for it. Thank you for the advice! :D

 

Btw, @nippur72: I want to make another system disk. I can figure out how to format it, but, what do I need to put on the new disk? Is there any "system header" needed to boot from it? Many thanks!

Share this post


Link to post
Share on other sites

@deepfb a system disk is a disk where the first 22 sectors contains the boot sector + DOS (which are loaded in RAM at boot). You can get them from disk #4. I also think you need an empty directory which is a sector placed at $02900 (see attached image).

 

Sectors are 256 bytes long and are interleaved when read from VT-DOS:

let sectors = [];
sectors[ 0] =  0;
sectors[ 1] =  3;
sectors[ 2] =  6;
sectors[ 3] =  9;
sectors[ 4] = 12;
sectors[ 5] = 15;
sectors[ 6] =  2;
sectors[ 7] =  5;
sectors[ 8] =  8;
sectors[ 9] = 11;
sectors[10] = 14;
sectors[11] =  1;
sectors[12] =  4;
sectors[13] =  7;
sectors[14] = 10;
sectors[15] = 13;

If we knew the disk interface protocol we could emulate it and attempt a warm boot. And then issue the INIT command.

 

The directory structure is very simple:

NAME, TRACK (byte), SECTOR (byte), STARTADDRESS (word), END ADDRESS (word)

post-31739-0-72413900-1539960501.jpg

Edited by nippur72
  • Like 1

Share this post


Link to post
Share on other sites

in this video you can clearly see what I was telling some posts ago: text is printed SLOWLY while in graphic mode because they used a set of DRAW commands that were previously manually encoded. This because the charset was not available -- it was not stored in the ROM (as in commodores) but in the video chip directly. So we had this basic subroutine we GOSUBed when we needed to print text in graphic modes. That's just one of the oddities of the Laser computer family.

 

I quote myself... in 2014 I mentioned the infamous DRAW routine used in games to display text.

 

I never imagined I would be able to see it again, but hey! we recovered it, and here it is:

11 GOSUB 40012
180 GR 3:MD=160
182 X=28:Y=110:C=15:A$="COPYRIGHT '86":GOSUB 40040
184 X=32:Y=145:A$="MULTIDIDACT":GOSUB 40040
186 X=32:Y=160:A$="B.V.  VENLO":GOSUB 40040:COLOR 15,0
192 X=0:Y=10:A$=" DEMONSTRATION GAME ":GOSUB 40040:COLOR 2,0
194 A$=INPUT$(1)
195 END
40000 REM INITIALISATIE PROGRAMMA
40012 DIM CAR$(90)
40021 FOR Z=32 TO 90:READ A$
40022 IF A$="STOP"THEN RETURN
40023 READ DA$:CAR$(Z)=DA$:NEXT:RETURN
40040 X1=X:Y1=Y:IF F=0 THEN F=1
40041 FOR M=1 TO LEN(A$)
40042 T$=MID$(A$,M,1)
40050 GH$=CAR$(ASC(T$))
40060 FOR N=1 TO LEN(GH$) STEP 4
40070 IF MID$(GH$,N,1)="/"THEN X=X+(8*F):GOTO 40100
40080 ZZ=VAL(MID$(GH$,N,1)):YY=VAL(MID$(GH$,N+1,1))
40082 JC5=X+ZZ*F:JC6=Y-YY*F
40083 JC7=X+VAL(MID$(GH$,N+2,1))*F:JC8=Y-VAL(MID$(GH$,N+3,1))*F
40084 MOVE (JC5,JC6):DRAW (JC7,JC8):COLOR C,0,0
40090 NEXT N
40100 IF X+8*F>MD THEN X=X1:Y=Y+10*F
40102 NEXT M
40103 RETURN
40140 NEXT N
40190 NEXT M
40200 RETURN
50000 DATA BLANCO,/,UITROEP!,31313337/,QOUTES,25274547/,#
50001 DATA 1353155521274147/,$,124242532444152626563137/
50010 DATA %,17271626125641514252/,&,121321315331155116273536/,'
50011 DATA 3536/,(,131513311537/
50020 DATA ),315353555537/,*,125616523137/,+,32361454/,COMMA
50021 DATA 21323233/
50030 DATA -,1454/,.,31423241/,/,1256/,0,12162141525627471256/
50040 DATA 1,214131372637/,2,115112334444555647271627/,3
50041 DATA 122121415253345617574453/,4,414713531447/
50050 DATA 5,122121415254154515171757/,6,214112151444525315373757/
50051 DATA 7,212223561757/,8,2141244427471213151652535556/
50060 DATA 9,113131535356245415162747/,.,33333535/,;,333232333533/
50061 DATA <,14471441/
50070 DATA =,13531555/,>,21545427/,?,16272747343331313456/,APE,/
50080 DATA A,11155155135315373755/,B,111717471444114152535556/
50081 DATA C,12162747475621414152/,D,1117114152561747/
50090 DATA E,1117115114441757/,F,111714441757/,G,12162757215151535343/
50091 DATA H,111714545157/
50100 DATA I,214131372747/,J,122121415257/,K,111713572451/,L,11171151/
50110 DATA M,11171735353435575751/,N,111751571652/,O,1216274756522141/
50111 DATA P,1117144417475556/
50120 DATA Q,12162747565321313351/,R,11171747565514442451/
50121 DATA S,1221214152532444151627474756/,T,17573137/
50130 DATA U,111721415157/,V,1317535713313153/,W,11175157113333513334/
50131 DATA X,111217165152575612561652/
50140 DATA Y,16175657163434563134/,Z,175712561151/
50150 DATA STOP

It's taken from the demonstration game "CITY INVASION" (soon to be published). Attached is the version you can run on the emulator or dump to WAV.

text_draw.bin

  • Like 1

Share this post


Link to post
Share on other sites

@deepfb a system disk is a disk where the first 22 sectors contains the boot sector + DOS (which are loaded in RAM at boot). You can get them from disk #4. I also think you need an empty directory which is a sector placed at $02900 (see attached image).

I was asking since I was planning to use a different disk drive, an Apple II-compatible 3" drive. As an Amstrad CPC user, I have more 3" disks than 5.25" ones :D Dou you know if there is a command to format/initialize the disk, and to automatically transfer the disk system to it? Or is there a command to backup the system disk? Thank you very much for everything! :D

 

 

I never imagined I would be able to see it again, but hey! we recovered it, and here it is

I am very glad to see it is being useful to you :)

Edited by deepfb

Share this post


Link to post
Share on other sites

If we knew the disk interface protocol we could emulate it and attempt a warm boot. And then issue the INIT command.

I added the information I have about the floppy disk controller/drive here.

I only have very basic info about the FDC I/O interface, but now that we have a DOS image, we can disassemble it to get more info, especially how to write data to the disk.

 

The track format on the disk is the same as the one used by Apple DOS 3.3. The hardware works pretty much the same way, except the Laser 700 uses 40-track disks (vs. 35 for Apple DOS), and the FDC does not have an embedded ROM.

 

Do you know if there is a command to format/initialize the disk, and to automatically transfer the disk system to it? Or is there a command to backup the system disk? Thank you very much for everything! icon_mrgreen.gif

You could try to plug both drives to the Laser 700, the 5"1/4 on port 1 and the 3" on port 2. The ROM only tries to boot from drive 1.

I do not have any documentation about the DOS commands, but the full list is: LOAD, SAVE, OPEN, CLOSE, BSAVE, BLOAD, BRUN, DIR, ERA, REN, INIT, DRIVE, IN#, PR#, DCOPY, STATUS, WRITE, ACCEPT, PUT and GET.

 

To be safe, remove the DOS system disk from the drive while testing those commands!

 

You could try "DRIVE 2" to select the 3" drive, and then "INIT" to format it. If that works, you can then swap the drives (after powering the Laser 700 off, of course icon_wink.gif ) and try booting from the 3" disk you just formatted to see whether the system was actually transferred to it.

 

The DCOPY command also looks interesting, but I would not experiment with it unless I already have at least 2 copies of the DOS system disk icon_smile.gif

Share this post


Link to post
Share on other sites

@Bonstra that's fantastic thanks! I'm going to integrate it in the emulator :-) This will also enable to create hardware emulators/adapters ! Great!

@deepfb I can confirm, from my old memories, the command is "INIT". It does format the disk and transfer the system/boot.

Share this post


Link to post
Share on other sites

@Bonstra that's fantastic thanks! I'm going to integrate it in the emulator :-)

I'm already working on it.

If you want to emulate the FDC, you should know that:

- there is some uncertainty about the I/O registers: I don't know what the 16 bit mode does, I'm not sure about the write sense bit polarity, and I don't know what signals are valid when no drive is selected.

- the .DSK image format is a very simple and high-level one (all the sectors data, already decoded, is concatenated). The Laser FDC however, just like the Apple II disk controller, works at a lower level, and the software has to do all the work of reading sector address fields and decoding data.

- you will need to emulate the disk at the "bit cell" level. I recommend this book which describes the disk format with more details than I did (only the disk format is relevant, with the difference that Laser disks have up to 40 tracks).

Share this post


Link to post
Share on other sites

Disk emulation is working ! (buggy, but working).

 

Many thanks to @Bonstra who did an awesome reverse engineering work (I'm really impressed) and to @deepfb who saved the VT-DOS disks from oblivion. Thanks guys!

 

I was able to boot from a virtual system disk... it's touching for me to see the DOS BASIC 1.0 prompt after so many years :-)

 

Still I can't read the old disks for some reason, but I can format new ones. Saving and loading seem to work nicely as well.

A big help came from the SDISKII project (http://tulip-house.ddo.jp/DIGITAL/SDISK2/english.html), the author published the sources to encode a disk into the Apple II format, so I modified it for the Laser (40 tracks, different interleaving) and converted the .dsk disk images that @deepfb has recovered.

// 0       Write protect sense: 0 = write-protected
// 	                        1 = not write-protected 

@Bonstra: I had to invert the "write protect sense" bit in order to make it work


post-31739-0-81806100-1540224915_thumb.jpg

  • Like 1

Share this post


Link to post
Share on other sites

¡Enhorabuena! Congratulations!!! I don't deserve too much credit for the disk images. I just dumped the floppies -it was a duty I had, not a job that needs a highly skilled operator :D

 

...And thanks for the tips on initilizing a disk. I will try it this weekend, and I will let you know if it works with a 3" FDD.

Share this post


Link to post
Share on other sites

 

4&4_pair(volume_num) // Volume number (usually 0)
4&4_pair(track)
4&4_pair(sector)
4&4_pair(checksum)
DE AA // Data end
(EB?)

 

@Bonstra, I've inspected an emulator-generated disk image and the "EB" byte is not there (but is present in the Apple ][ protocol).

 

Another difference is that "volume_num" in Laser500 is zero while it's 0xfe on the Apple ][.

Share this post


Link to post
Share on other sites

Disk emulation is working ! (buggy, but working).

Nicely done!

 

I was able to boot from a virtual system disk... it's touching for me to see the DOS BASIC 1.0 prompt after so many years :-)

Well, disk 3 even have a DOS BASIC 1.1 icon_wink.gif

 

 

// 0       Write protect sense: 0 = write-protected
// 	                        1 = not write-protected 
@Bonstra: I had to invert the "write protect sense" bit in order to make it work

 

Indeed, fix applied!

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...

  • Recently Browsing   0 members

    No registered users viewing this page.

×
×
  • Create New...