oh my the old days :)

edited July 2008 in Sinclair Basic
programming on the speccy again

here is a routine i remember of the top of my head to load screens or code without a header wow

5 Clear 27999 : Rem clear memory for usr 28000
10 Border 0 : Paper 0 : Ink 7
20 Cls
30 For i = 0 TO 12
35 Read a
38 Poke 28000+i,a
39 Next i

50 Data 221,33,0,64,17,0,27,62,55,205,86,5,201

60 Print "I am loading your code"
70 Randomize Usr 28000

structured break down of the data

221,33 = start of the code

0 = high byte
64 = low byte

for example 0,64 0+64*256 = 16384 (code to load screen$)

17

0 = high byte
27 = low byte

for example 0+27*256 = 6912 (This is the basic length of screen$)

86,5 is calling the load routine from rom

i.e 5*256 + 86 = 1366



201 end



just a memory reload thats all

and i just thought i would add my penny's worth

Lee B
Post edited by wadfm on

Comments

  • edited June 2008
    Nice. I also call the ROM routine, but I always get confused with the low and high byte calculations. :lol:

    Regarding the 'Clear' command, I think it should have a value of 27999.
  • edited June 2008
    yes your right zx

    clear 27999

    as i say it was off the top of my head

    i was close

    lol

    i was just sat here yesterday and wondered that how to load the code like from specdrum because there was no header and woohoo i did it

    Cheers

    Lee :smile:
  • edited June 2008
    i used to put that code above 60000, so clear 59999 works for me, :P
    So far, so meh :)
  • edited June 2008
    Doesn't work for me! Is it Microdrive sensitive?
  • edited June 2008
    hmmmm microdrive maybe not as it accesses the rom for tape loading but maybe with a few tweaks it could

    as i say this bit is the data to access the rom

    50 Data 221,33,0,64,17,0,27,62,55,205,86,5,201

    the 86,5 is the rom access

    5*256 =1280

    then add the 86 as the low byte to it and this gives you 1366

    if you randomize usr 1366 the screen will go blank but try pressing play on the tape then it will try to look for code , pressing space bar cancels as normal

    if you can find out what the microdrive uses as part of the speccy rom then you should be able to modify this

    but also remember this is for loading headerless files

    hope this helps

    Lee B
  • edited June 2008
    polomint wrote: »
    i used to put that code above 60000, so clear 59999 works for me, :P

    indeed on this i forgot that when you clear code its always -1 to the randomize usr xxxxx

    but i cleared it lower because the code i am loading in uses 30000-64000 specdrum software code for example.

    its only a bit of fun but it is good to bring back these memories from the 80's

    wow is it really that long ago

    lee
    :lol:
  • jpjp
    edited June 2008
    zxbruno wrote: »
    ...Nice. I also call the ROM routine, but I always get confused with the low and high byte calculations. :lol:...

    Some functions might help... courtesy of Ian Hoare's "Task Force" column in Your Sinclair Issue 1, page 29:
    10 DEF FN h(y)=INT (y/256): DEF FN l(y)=y-256*FN h(y)
    

    e.g.
    PRINT FN h(32768),FN l(32768)
    

    would return
    128,               0
    


    The other alternative is:
    LET y=32768: RANDOMIZE y: PRINT PEEK 23671, PEEK 23670
    

    which returns
    128,               0
    

    Either way, both these methods could be adapted into the headerless code loader.
  • edited June 2008
    nice one jp

    excellent way on how to determine low and high bytes well found out

    ;)

    Lee
  • edited June 2008
    I can't make it work! It starts to load, but just for a split second, and then stops with the OK message!

    I've copied it exactly and am playing a tape with a saved SCREEN$ on it. (Play past the header and then call the routine).

    Am I being thick? What is wrong??!!
  • jpjp
    edited July 2008
    gcallard wrote: »
    I can't make it work! It starts to load, but just for a split second, and then stops with the OK message!

    I've copied it exactly and am playing a tape with a saved SCREEN$ on it. (Play past the header and then call the routine).

    Am I being thick? What is wrong??!!

    If you disassemble the code, there's a bug:
    ld ix,16384
    ld de,6912
    ld a,55
    call 1366
    ret
    

    The 'a' register needs to be either 0 to signify a header, or 255 to signify data - change the 55 in the program to 255 and that should work. There's also the carry flag to signify whether the rom routine should be LOADing or VERIFYing. All the detail is here here
  • jpjp
    edited July 2008
    Oops, here's a fixed version:
    10 CLEAR 27999
     20 BORDER 0: PAPER 0: INK 7
     30 CLS 
     40 FOR i=0 TO 13
     50 READ a
     60 POKE 28000+i,a
     70 NEXT i
     80 DATA 221,33,0,64,17,0,27,62,255,55,205,86,5,201
     90 PRINT "I am loading your code"
    100 RANDOMIZE USR 28000
    110 PAUSE 0
    


    The machine code itself:
    ;
    	org 28000
    ;
    main	ld ix, 16384		 ; 28000 221 33	 0     64	 14ts
    	ld de, 6912		 ; 28004 17     0	 27     10ts
    	ld a, 255		 ; 28007 62     255 7ts
    	scf			 ; 28009 55     4ts
    	call 1366		 ; 28010 205 86	 5     17ts
    	ret			 ; 28013 201 10ts
    

    You can download it here with sample headerless screen
  • edited July 2008
    That'll be it then! Thanks!
  • edited July 2008
    sorry about that guys

    yes i did miss off the 255 shoot sorry

    10 CLEAR 27999
    20 BORDER 0: PAPER 0: INK 7
    30 CLS
    40 FOR i=0 TO 13
    50 READ a
    60 POKE 28000+i,a
    70 NEXT i
    80 DATA 221,33,0,64,17,0,27,62,255,55,205,86,5,201
    90 PRINT "I am loading your code"
    100 RANDOMIZE USR 28000

    as i say it was off the top of my head and it has been 20 years since i did this on a speccy lol

    but thank you jp for correcting

    and sorry to all who tried it and found out the error

    Lee B :)
  • edited July 2008
    I must start getting back in to program this little wonderful machine
    again
  • edited July 2008
    You can also save one byte by changing the 205 (CALL) by 195 (JP): ROM's LOAD routine's own RET will take care of returning correctly to BASIC. ;-)

    This way you may chop off YOUR final 201 (RET) byte. :-D

    Regards,
    Marcelo.
  • edited July 2008
    oh yes marcelo i remember something about that

    nice one

    lee :p
Sign In or Register to comment.