Very interesting. I didn't expect it to work well enough to be of use
on SAM, given how limited memory accesses are. Does the CPU manage to
run at all while the DMA is active?
Is it possible to achieve the same result with an external board
replacing the internal CPU? My soldering skills
On 11/08/2014 12:19, Solaris104 wrote:
I played this game and I found a bug in the level 3 (rating crazy),
password NEYLEKNO. Does it exist any fix and level codes for this game?
Solaris104
What is the bug you think you found? I've just tried it here and that
level does start correctly for
Hi David,
I've still got an audio cable set up from my SIAC, so drop me a line off
the list and we'll sort something out. I'm not much of an E-Tracker
user, so anything that's as ready to boot and play as possible would be
appreciated :)
Cheers,
Si
On 21/04/2014 00:03, David Sanders wrote:
The fault location doesn't ring any bells, though it appears DirectDraw
on Vista (or later) is emulated using GDI+. I'll send you an updated
build to try, which also uses D3D by default so it should look much
better than the blocky software version. I'll still see if I can
reproduce the issue
I've got a Win32 binary for the current SVN build that you can try... The
sounds code is built-in now, so there won't be a problem with that particular
SAASound.dll.
Most virus-scanner false-positives I've run into have been related to using UPX
to compress the modules. Seems odd that an
I'm sure I've got a spare I can donate... I'll have a check and be in
touch!
Si
On 01/06/2013 17:01, Chris Pile wrote:
Hi SAMsters,
A bit of a long shot really, but thought I'd try here!
Does anyone have a spare (working) SAM floppy drive and controller
they'd be prepared to get rid
On 24/03/2013 01:51, Tommo H wrote:
I got as far as discovering that SAM Coupé diskimage Manager v1.12 by
Edwin Blink would allow you to liberate the files from the Sam disk
image to a Windows PC; there must then be a tool for throwing them
onto a Spectrum TAP or DSK.
Transferring the
Will any clones still have a 6MHz mode, with memory timings identical to
the original hardware? A higher proportion of SAM software depends on
them for video effects, compared to what you'd see on the Spectrum.
Si
On 24/03/2013 14:28, Leslie Anderson wrote:
Hi.
I'm new to the SAM COUPE group
On 17/02/2013 11:44, Marcos Cruz wrote:
It works fine. Only the full-screen mode does not work on X Window.
Simon explained there's no solution yet.
I tend to run outside of X as it's slightly faster, which can be needed
for demos that change much of the display each frame. Though I've just
On 15/01/2013 20:51, Stefan Drissen wrote:
Just a heads up that a spammer has hit worldofsam.org with four crap
comments.
I've deleted them now. The username of 'sam' felt a bit more targeted
than usual!
Si
Hi Marcos,
The SAM palette is make up using 2-bit RGB plus intensity, which bitwise
is: xGRBigrb. For pure greys you'd use:
= 00 = 0
0111 = 07 = 7
1000 = 08 = 8
= 0f = 15
0111 = 70 = 112
01110111 = 77 = 119
0000 = 78 = 120
0111 = 7f = 127
The SAM demo
Hi Marcos,
If it's of any use, I did a quick hack version of my shamview converter to keep
the full image at 16 colours. It scales the source image to 256x192 and
converts to SAM palette, then picks the top 16 colours to use for a final
conversion. Script is here:
On 16/11/2012 18:59, Thomas Harte wrote:
What's your policy on native code? I ran a quick test with:
I try to avoid native code in the SDL version, where possible, but it
seems like it might be the best option. It can probably go in SDLMain.m
without too much trouble -- thanks! :)
Si
On 15 Nov 2012, at 22:57, Marcos Cruz wrote:
What do you mean auto-typed? Text spooling?
Yep, that's it! It's currently a Windows-only feature at the moment, but I'll
extend it to support other platforms.
AFAIK SimCoupe lacks a file spooling option (in fact it is what I need:
SimCoupe to
On 16/11/2012 16:15, Marcos Cruz wrote:
the text is converted before auto-typing it. Isn't it? I mean
non-ASCII characters.
Yes, in the simplest case it's just to map £ and © to the special codes
needed for SAM use, and to drop CR but convert NL to CR. Though I
also use the Win32 API to do
It's great to see more new content! I just wish I could get more than 2
steps up on the first screen. I'm just recovering from a Super Hexagon
addiction, so I do like my games tough ;)
Si
On 14/11/2012 16:08, Andrew Gillen wrote:
Hi, just to let you know I have finally finished writing Dave
This sounds like a problem I was looking at with Josef a few months
back, where long ported programs failed on SAM. As far as I could tell
it was a bug with LABEL management -- his problem listing used many
labels (no use of KEYIN). I was able to narrow it down to a boundary
case, as
repeatedly died at the 7 second mark.
I'm a bit better at it now. I do love the game.
On Thu, Nov 15, 2012 at 2:36 PM, Simon Owen simon.o...@simcoupe.org
mailto:simon.o...@simcoupe.org wrote:
It's great to see more new content! I just wish I could get more
than 2
steps up
On 12/05/2012 22:34, Aleš Keprt wrote:
We have the program done, including graphics and music. I also added a
tiny text scroller and now I need to write some text to put there. :-)
Did you ever finish this? It'd be great to see how it compares to the
Speccy version.
Si
On 04/09/2012 16:23, sam.co...@centrum.cz wrote:
According to his other words (and the SAM Revival interview with Mr. Wright)
I think these discs have original asm-texts...
Anyone could help to contact Simon?
I asked Simon about this at the Spectrum 30 show yesterday. He does
have some
On 02/08/2012 23:16, VELESOFT wrote:
Exist schematic or PCB photos of this interface ?
I don't have a schematic, but I have some photos somewhere. I'll send
them on if I can find them, or take some more.
Si
On 30/07/2012 17:39, wayne wrote:
Tried to build Simcoupi on my recently aquired RPI.
There was a missing component in the SourceForge path, fixed now! The
newer distro also simplifies things slightly, so I'll post updated
instructions when I get a chance.
In the meantime, try this updated
On 14 Jun 2012, at 09:23, Chris Cowley wrote:
I have my favourite text editor and pasmo set up, which I use for occasional
speccy stuff, and
have augmented this with pyz80
I use the same mix of pyz80 and Pasmo for SAM and Speccy development, along
with my favourite text editor. In both
On 14 Jun 2012, at 22:50, Andrew Collier wrote:
I recently discovered Pixen, which is designed for just that sort of thing.
Mac OS only, though.
That looks promising — thanks! It's no problem being Mac only as it fills the
hole I had with palette-based pixel editing. Though curiously my
On 5 Jun 2012, at 01:32, Chris Cowley wrote:
I've done a SAM-specific version of my little BorderTron
Nice work — didn't expect you to do it so soon!
My first design ended up off the left of the screen, so perhaps it's worth
reducing the editable area to just the visible display? That'll
On 18 May 2012, at 00:56, Tommo H wrote:
If I have, say, 40% of a frame to spend on it, how many sprites, and how
large, is it realistic to expect to be able to draw and un-draw?
Maybe around 4-5 sprites of 16x16 pixels? IIRC my Pac-Man emulator has about
half a frame to draw 6 sprites of
On 13/05/2012 10:14, Andrew Gillen wrote:
There seems to be a lot of talk about timing critical border effects
for the ZX Spectrum. Anyone got any information on achieving the
same sort of effects on the SAM?
It's much the same on SAM, just with different timings and alignment:
- longer
On 13/05/2012 10:14, Andrew Gillen wrote:
it created some nice patterns, but not quite the patterns I wanted.
Try working from this: http://obo.homeip.net/BorderSAM.zip
The visible width is 36 blocks, and each out covers 2 blocks. That
means 18 OUTs for the effect plus 6 more for invisible
On 06/05/2012 11:48, Mike Nicholas wrote:
The disks I purchased no longer work and I wondered if anyone knew if it
is possible to get a DSK/SAD image for these games?
I have Multipack 1 in EDSK format (it has a blank track that can't be
represented in the simpler DSK or SAD formats).
It looks
On 05/05/2012 01:27, James R Curry wrote:
Hangs on boot in SimCoupe for me
BDOS appears to get stuck in a loop accessing the 2nd drive. With an
Atom interface connected it's waiting for the HDD to be ready. With a
floppy drive present it's waiting for the FDC data register to change,
which
On 05/05/2012 14:52, David Sanders wrote:
the only issue I'm having is that E-Tracker 1.2 is utterly confused
by it - to the point that I actually have to disable the 2nd drive
to get it load modules.
The good news (well, for me!) is that it's the same with real hardware.
Unplugging the
On 05/05/2012 14:52, David Sanders wrote:
the only issue I'm having is that E-Tracker 1.2 is utterly confused by it
I get a Fatal Error message accessing the disk with Atom BDOS, AtomLite
BDOS and even SAMDOS v2. I noticed the E-Tracker comes with MasterDOS,
so perhaps it's relying on features
On 05/05/2012 17:15, Simon Owen wrote:
perhaps it's relying on features in that that's causing the problem?
I can confirm there's a sprinkling of MasterDOS-specific code, including
DSTAT and DIR$, which will need to be re-written.
On the plus side, all the disk access appears to be done from
On 24 Apr 2012, at 21:29, Simon Owen wrote:
Getting most of it running probably wouldn't take very long, but getting the
timing right could be a challenge.
Changing the 128K screen flips and crudely tweaking the DJNZ timing loops gives
this: http://obo.homeip.net/nyanhack.gif (loop every ~4
On 25 Apr 2012, at 15:23, Andrew Collier wrote:
I don't have a copy of KR to hand, but I reckon this is ambiguous (i.e. the
value of g_dwCycleCounter7 depends on the whether this is evaluated before
or after the += 4. Honestly I'm a bit surprised that the left hand side is an
lvalue at
On 23 Apr 2012, at 21:35, James R Curry wrote:
Just port the original.
I've had a quick look and there are oodles of unrolled code blocks and fixed
delay loops for display timing. Getting most of it running probably wouldn't
take very long, but getting the timing right could be a challenge.
On 23/04/2012 16:16, Tommo H wrote:
Vaguely related: does anyone know where I can get hold of Sam dos as a
binary blob, outside of a disk image, for the purposes of being able
to assemble things conveniently?
Most of my SAM projects on GitHub should include samdos2. They also use
pyz80's -I
On 23 Apr 2012, at 18:10, Tommo H tomh.retros...@gmail.com wrote:
The SDL you've linked with appears to be broken under 10.7 in some
ways, especially relating to the way the new OS supplies help in
restoring sessions
It might be worth checking you're using SimCoupe 1.0a for OS X, as that
was
On 20 Apr 2012, at 17:25, Aleš Keprt wrote:
I’d like to know why do you use Amstrad CPC file format, instead of a
standard Sam Coupe one (DSK/MGT or SAD).
EDSK has been an adopted format in the SAM scene at least as far back as 2005.
It's the only way to preserve some disks in their original
formats.
Aley
From: Simon Owen
Sent: Friday, April 20, 2012 7:36 PM
To: sam-users@nvg.ntnu.no
Subject: Re: Musics
On 20 Apr 2012, at 17:25, Aleš Keprt wrote:
I’d like to know why do you use Amstrad CPC file format, instead of a
standard Sam Coupe one (DSK/MGT or SAD).
EDSK has been
On 16/04/2012 16:17, Tommo H wrote:
Versus running it on a normal computer, do we get genuine 50Hz output?
Setting an option in /boot/config.txt overrides the auto HDMI mode, so
it's be easy to force 50Hz (it'd be even better if it could selected on
demand at runtime). Composite defaults to
Seems like a promising start: http://simonowen.com/raspberrypi
Speed is fine with the normal SDL build, even with demanding titles like
MNEMOdemo1 part 2. It ran at about 450% with the emulator turbo button held
(max speed but video capped at 5fps).
The OpenGL version ran very slowly in X, as
Quoting Simon Owen simon.o...@simcoupe.org:
Seems like a promising start: http://simonowen.com/raspberrypi
Speed is fine with the normal SDL build, even with demanding titles like
MNEMOdemo1 part 2. It ran at about 450% with the emulator turbo button held
(max speed but video capped at 5fps
On 16 Apr 2012, at 15:48, Wayne Weedon wrote:
I just get a 403 error following that link.. Do you have some .htaccess rule
in there somewhere?
Oops! In case of caching, try this instead: http://simonowen.com/simcoupi
I renamed the album title and that must have changed the link somehow. A
On 16 Apr 2012, at 16:13, Andrew Collier wrote:
It still amuses me that the biggest side-effect of my contributions to
the Sam scene was to necessitate accuracy in the emulators :)
Getting the textured scroller right in part 2 of MNEMOdemo1 was definitely a
grail moment, where everything had
On 16 Apr 2012, at 16:17, Tommo H wrote:
Having managed to get hold of a Raspberry Pi differentiates you from
99% of the world; using Google+ differentiates you from 99.9%.
The images were uploaded from Picasa, to something which used to be called
PicasaWeb. It looks like Google have pulled
Bonus points if you then run SimCoupe on it, to see if it still feels wrong!
I created a quick SimCoupe binary for the Raspberry Pi back in Feb, which I've
tested in the development VM under QEMU. Still waiting for real hardware to
see how well it runs though. I was kinda hoping I
Thanks for that Ian — it does sound very similar to what I was aiming for.
Though the standard screen$ capabilities seem very limited, with maybe just 1
change per line? (plus flash)
I've had a few more ideas about how to handle a running palette, with it tied
into knowledge of SAM's display
Perhaps Aley only sees the practical applications, and what he feels is
useful? If something that already exists, why would anyone want to
re-invent it, etc.
I'm quite the opposite, and a big fan of because-it's-there. I'll
happily spend hours investigating and implementing minor emulation
I'm hoping a Raspberry Pi, USB CF reader and SimCoupe will pretty much
satisfy that, if it runs fast enough.
If the CF card is just for Atom Lite use, you'd probably be better off
with a an HDF image on the boot SD. Or if you want to share with a
desktop machine, maybe a low-profile USB stick
On 12/04/2012 23:34, Simon Cooke wrote:
Btw... I think the link to the dsk is busted right now...
Oops, yes -- fixed now! :)
It's possible the broken redirect is cached, so try:
http://simonowen.com/sam/shamview/shamview.dsk?x
Si
On 11/04/2012 22:42, Stefan Drissen wrote:
Is the palette being adjusted multiple times while the line is being
drawn (similar to the rainbow processor effects on the Spectrum)
No, only outside the image being drawn, for now.
how many t-states are available between line end and next line
On 4 Apr 2012, at 23:54, Andrew Collier wrote:
I fear it might be some kind of attempt at reprisal for me blocking his
worldofsam account due to his spamming and abusing other users, so apologies
to anyone who is getting affected by the crossfire.
I've received the same e-mail with 157
On 2 Apr 2012, at 02:05, Aleš Keprt wrote:
So how many colours are possible per line in this format? Or what is possible
in this picture format?
The number of colour changes per line depends on the image width, as CLUT
changes are only made outside the image. That gives 6 dynamic and 10
On 2 Apr 2012, at 23:58, Thomas Harte wrote:
I think that used a tight loop of something like (i) load next palette index,
next colour and next delay length; (ii) push colour to palette index;
(iii) perform a busy loop of the desired length; (iv) repeat.
That's closer the approach I was
On 28/03/2012 19:27, Aleš Keprt wrote:
My final choice is Microsoft ADPCM, its bitrate is 384 kbps (for 48kHz
stereo), i.e. 172 MB per hour, and I think the audio quality is good.
I tried ADPCM for SimCoupe but wasn't very happy with it. MS-ADPCM was
brighter than IMA-ADPCM, but still seemed
On 30/03/2012 21:15, Aleš Keprt wrote:
I think the audio track needs to be compressed to MP3 in an external program.
MP3 would have been good, though I don't know if finding a legal free
codec for the encoding might be a problem? The demo AVI I posted a few
years ago was run through VirtualDub
On 30/03/2012 22:01, Aleš Keprt wrote:
So you use your own MRLE encoder instead of Microsoft's codec? How does
it work?
Yes, the MRLE encoder is fairly simple, and probably under 100 lines of
code. The audio data is exactly what's written to the sound card
buffer, so that didn't need encoding.
Hi all,
I've been experimenting with HAM-style tricks on SAM, to try to improve
the quality of converted images. I've aimed to modify as many colours
as possible between lines, rather than using the traditional compromise
static palette. Are there any viewers using that technique already?
I've
Previously I wrote:
It should still be possible to add a USB sound device, at the cost of
one USB port. Hopefully not too much extra latency either.
I've just tested this out with my HP Microserver Linux box, which also
lacks sound hardware. I had a USB sound device that came with my
On 17/02/2012 20:27, da...@properbastard.co.uk wrote:
would it be possible for the raspberry pi to run SimCoupe ...
I'd expect the OpenGL SDL version should build and run on it without
any trouble. I'll certainly give it a whirl once I get one.
My only concern is the sound hardware on the
On 15 Feb 2012, at 13:48, Dave wrote:
Here's a fun clip from the first show at Gloucester. So long ago I
don't remember what year it was, but it must've been something like
'93/94.
Fantastic! A lot of familiar faces, and some others I can guess from context
(maybe watching with sound would
On 10 Feb 2012, at 00:10, Thomas Harte wrote:
started dumping a whole bunch of my old projects onto GitHub
Spookily enough, I started dumping some of my SAM+Speccy projects on there a
few days ago! I also added the SAM ROM source, which was converted to
pyz80/Comet format, corrected to match
On 2 Feb 2012, at 10:24, Geoff Winkless wrote:
If you're thinking of playing with stuff like that in SimCoupé, how
about adding in a screen start address OUT mod? I'd love to see what
could have been done with just a small change to the ASIC design :)
I was drawn by the possibility of there
On 2 Feb 2012, at 10:43, Thomas Harte wrote:
emulator authors tend to be quite parochial and superstitious about this
stuff for some reason, hence e.g. the mostly invented black scan lines a lot
of them like to insert.
I find a partial scanline effect helps soften a harsh pixelated image,
On 2 Feb 2012, at 10:24, Geoff Winkless wrote:
how about adding in a screen start address OUT mod?
Would that be possible with a real SAM peripheral? Can the value on the bus be
changed to redirect the display read? Or is it possible to modify the value
read instead? Perhaps something that
On 2 Feb 2012, at 11:50, Geoff Winkless wrote:
If you could just change that 15-bit offset to start at XhXl using
The emulation side doesn't keep it as a pure offset, but from what I remember
it should still be relatively easy. There might be some funky side-effects for
attributes in mode 1,
On 01/02/2012 20:07, Thomas Harte wrote:
I notice that whatever effect it thinks it is relying on doesn't work
in Sim Coupe.
It's certainly nothing that's implemented at the moment, but if it's
shown to be a real effect (like border pixels), it should go in. Though
it does feel like it could
Great job with your game, especially as a first in Z80! As well as
Manic Miner I got a hint of Jasper from it for some reason.
I'm also a fan of the sideways screen wipe, which feels very arcade
retro. I didn't notice any issues with the collision detection, though
I did struggle to spot the
:
key repeats?
is it impossible to run 48 emulator snapshots in external ram?
On 24 October 2011 14:35, Simon Owen simon.o...@simcoupe.org wrote:
Hi Ian,
I'm hoping fixed running rates will come 'for free' as part of the switch
to audio-based synchronisation (rather than the current timer
Hi Ian,
I'm hoping fixed running rates will come 'for free' as part of the switch to
audio-based synchronisation (rather than the current timer method).
In the meantime, if you don't actually need the key repeats, try this patched
ROM to disable them:
On 16 Oct 2011, at 15:03, ellvis wrote:
Results were that I got only half of the directory visible and after
any file load I've got 108 End of file and the data were just mess.
MGT (old-style DSK) uses a track order of:
c0h0, c0h1, c1h0, c1h1, c2h0, ...
BDOS records and SAD images use:
c0h0,
Hopefully we understand the behaviour of the current ASIC well enough for
someone to create a replacement, or (as you're suggesting) and enhanced version
that is backwards compatible. It's not a small task though!
I have a bunch of test programs that Dave and I wrote for SimCoupe, which
Thomas Harte tomh.retros...@gmail.com wrote:
my USB floppy drive showed up as a block device and exposed only the
PC-style double density sectors as blocks.
That's just how USB floppy drives are seen by the system, and is the
reason they're so limited. The LBA to CHS mapping is internal to
Dicky Moore wrote:
Has anyone had any luck in copying Sam-formatted floppy disks to .dsk or
.mgt images using a USB floppy drive?
Samdisk doesn’t support USB floppy drives and I’m not sure of any other
software that can do this.
I'm afraid there's no way to do it with a standard USB floppy
David Brant wrote:
Just to put a spanner in the works. JP's are faster in external memory.
You're right! External memory is uncontended, so it's as fast as the
ROM. SimCoupe does already implement that correctly, so it's just my
memory at fault.
I ran a test incrementing BC in a tight loop
Chris Pile wrote:
In short, then, I guess I should ignore what Zaks is telling me
regarding T-states and simply try to use single/double byte
instructions wherever and whenever possible?
As a very rough guide, round the official instruction timings up to the next
multiple of 4, then double
David Brant wrote:
Just to put a spanner in the works. JP's are faster in external memory.
JR and JP will both be 12T in external memory, which is the same speed as they
are in internal RAM during the border area. External RAM gives the same speed
boost as disabling the display, by avoiding
On 26 Apr 2011, at 10:25, Geoff Winkless wrote:
Would it have been better to have 48kB of more expensive display memory,
giving only the live display and a secondary (for double-buffering) but
losing the ability to use any page in RAM as the screen?
snip
For me the real mistake, though, was
On 26 Apr 2011, at 12:46, Geoff Winkless wrote:
On 26 April 2011 10:55, Chris Pile chris.p...@blueyonder.co.uk wrote:
Some sort of blitter to chuck large blocks of data around at high speed would
have been
a *very* nice addition. That 24k screen really is too much for the old Z80
to cope
Hi Chris,
The short answer is Yes, it's best to use JR e over JP nn on SAM.
In the best-case border area, both are 12T. Fully on the main screen,
JR is typically 16T and JP is a whopping 24T. It does depend a little
on the starting cycle alignment, and instructions spanning the screen
edges
This is becoming more of an issue, with Macs and newer desktops not having a
motherboard floppy controller, and more widespread use of laptops...
Almost all USB floppy drives are usually limited to 720K (9-sector) and 1.44M
(18-sector) formats. They contain their own floppy controller chip,
.
Is it a complete impossibility? ;-)
Quoting Simon Owen simon.o...@simcoupe.org:
On 4 Apr 2011, at 16:02, Simon Cooke wrote:
If SimCoupe uses rdtsc without setting the CPU thread affinity, there are
issues on some systems where it loses track when the thread is scheduled
onto another CPU core
On 3 Apr 2011, at 23:26, Andrew Gillen wrote:
All development and composing has been on Sim Coupe so far. The guy doing the
music has redone the module from scratch, and made it a lot longer. This time
round most of it plays fine until about 40 seconds in when some of the
channels come in
Hi Nev,
If it's not too many disks I'll offer my services to dump them for you. I've
got a 3 drive with a PC adapter and SAMdisk will dump them to a suitable
format. Or you're welcome to borrow my hardware and do it yourself, depending
on how sensitive the contents of the disks are.
The
On 19 Jul 2010, at 22:47, Stefan Drissen wrote:
Now hurry along Si and integrate the label.tab in SimIce… ;-)
If it's just symbols you want tied in, I'm sure that can be arranged :)
You may want to ask David to add page information to the label.tab file first
though. ;-)
Speaking of
Adrian Brown wrote:
If its emulating the SID then id be worried about copyright. The SID
interface is a current piece of hardware and as far as im aware there
has been no rights granted to emulator its ability.
Technically, it's just a SID chip connected to the expansion port, so
what is
Andrew Collier wrote:
He didn't include code, but he described counting the number of NOP
instructions executed between two consecutive frame interrupts.
I've knocked up my own version, which uses the block of NOPs, but with a
DEC A ; JP Z at the start to exit once the test is complete. They
Simon Owen wrote:
The value I get in SimCoupe is 119792
I'll check it's the same on the real machine tonight.
Same same.
Si
Simon Cooke wrote:
I was wondering… does anyone have a fully-detailed breakdown of
instruction timings for the SAM? Including at various points in the
screen?
It's hard to have a complete list for anything but the smallest
instructions. For longer instructions it depends on how they
fall
Andrew Collier wrote:
I think the only question it doesn't answer is what happens to the
112 t-state difference between the number of t-states measured with
the screen off (119696) and the number that would be expected from
the timing characteristics of the screen display (119808).
Doesn't
Thomas Harte wrote:
surely it'd be easiest just to write a routine that shoots out new
palette values as quickly as possible
It depends how controlled the changes need to be...
An unrolled block of OUTI instructions can make 13 changes across a main
screen scanline (including both borders).
Andrew Collier wrote:
That would mean there should be 384*312=119808 t-states between frame
interrupts, but according to that article, if you measure the number
of instructions executed during a frame, then even with the screen off
it turns out to be slightly fewer than expected.
I'd be
LCD wrote:
But just a idea: Using Stack Pointer (PUSH) to write in CLUT
memory area would be faster than LD Command, right?
It certainly would be if SAM's palette was memory-mapped. Unfortunately
it's only accessible through 16-bit I/O ports, so we're limited to the
slow updates of each CLUT
Earlier I wrote to Thomas Harte:
I don't currently own a regular SD card, so I'm not able to try it
myself. I'll see if I can pick one up in the next couple of days
I managed to acquire a 1GB SD at lunchtime, so I've had a quick go. It
uses normal byte ordering like Atom Lite, so you just
Andrew Collier wrote:
- an implementation of the inflate decompression algorithm from RFC1951,
as used by gzip and other compatible utilities.
Very nice!
Can it be fed straight gzip file data, or does it need the file header
stripping from it first? I think I usually pass everything to zlib's
Thomas Harte wrote:
but is there any solution yet for an entirely solid state Sam?
I have an Atom [Lite] card in the drive 2 slot, and use Edwin's modified
ROM to boot directly from it. As a bonus, you can use the CF card with
SimCoupe on your desktop machine to share all the same programs and
David Brant wrote:
I'm using mode 2 interrupts when I use sim coupe's debugger I get the
normal frame interrupt and then a interrupt at line 0 point 52 (real
line not SAM coupe line) anyone know whats producing it?
It still sounds most likely to be a re-triggered interrupt, even if the
status
Thomas Harte wrote:
is anybody able to loan copies of Prince of Persia, Lemmings, Defender
and anything else particularly worth showing?
I'm planning to go to the show too, so I should be able to bring any
software (or even extra hardware) you need. I've got a SAM In A Can
too, with Quazar
Thomas Harte wrote:
Although I'm aware that my USB drive may be hard coded somehow not to
support anything other than the PC layout
That's pretty much it I'm afraid! USB floppy drives are seen as simple
block devices, and the linear-CHS mapping is done inside the unit. I
believe DD disks
1 - 100 of 434 matches
Mail list logo
